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Althouyh  an  Important  new  project,  the  Atlantic  PaoKot-  Satcllire 
Project  (PSP)  started  in  1975,  our  practical  involvement  in  tno 
experimental  programs  began  only  in  1976.  During  this  piariod  a 
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ASST PACT 


This  report  serves  as  a final  report  on  a contract 
from  the  Office  of  Naval  Research  (NOOO 1 4- 74-C-02 30 ) 
vhich  terminated  on  30  September  1976,  and  as  the  first 
quarterly  report  on  Contract  NOUO  1 4- 7 7-0-000  9 ■.•;n  • cn 
began  on  1 October  19/6.  Research  activities  ocvt-rcd  in 
this  document  include  the  interconnection  of  nosts  .nd 
networks,  the  development  of  a system  SWI'I  CH  f ■.  irvuai 
network  connection,  and  our  connection  to  the  UK  Post 
Office  Experimental  Packet  Switched  Service.  Ta’  .pirs 
covered  in  particular  detail  are  the  Packet  Sat'OiJte 
Project  and  the  Transmission  Control  Procrair  'T''" 
experiments.  These  have  particular  relevance  to  othei- 
ARl’A  supported  projects  and  so  are  treated  in  S'--^  '’cpth. 
Finally,  our  measurement  and  facsimile  activities^  ue 
described,  and  UK  use  of  ARPANET  through  the  UCT  Ttt-  ^ c; 
evaluated.  A list  of  conclusions  that  may  be  drawn  from 
our  research  activities  during  1976  is  given  at  tf.e  t ;d 
of  the  report. 
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CHAPTER  1 : INTRODUCTION 


1 . 1 Purpose  of  the  Keport 

The  University  Colie.-je  London  Aid’A  Projeot  started 

in  1973.  The  original  contract  from  t!.<-  Office  of  Nav^al 
Research  ^NOOD 1 4-74-C-0280 ) , was  renewed  up  to  September  30 
1976;  a new  contract  (NOOO 1 4-77-G-OOO 5 ) , started  on  October  1 
1976.  This  report  serves  therefore  as  a final  report  on  the 
first  contract,  and  as  the  first  quarterly  report  on  the  second. 
The  project  is  also  partially  financed  by  the  British  Library 
(BL,  GRANT  SI--G-093),  the  UK  Ministry  of  Defence  ^MOD,  Contract 
AT/2047/064),  and  the  UK  Science  Research  Council  (SRC,  GRANT 
B/RG/59811  and  B/RG/67022).  The  report  is  tnereferc  also  an 
annual  report  for  these  grunts  and  contracts  a.s  were  the  previous 
annual  reports  (Kirstein,  1974  and  Kirstein  1976A) . Support 
has  been  provided  by  the  UK  Post  Office  to  the  Packet  Satellite 
Project,  and  this  report  is  also  aim.ed  at  informing  them  of 
the  progress  of  work. 

Tv«  subjects,  the  Packet  Satellite  Experiment  (Chapter  7)  and 
the  TCP  (Chapter  5)  are  treated  in  particular  detail.  This  is 
because  those  sue jects  are  of  particular  relevance  to  other 
ARPA  supported  projects,  and  this  report  is  a final  report  for 
ONR  N000l4-74-C-2B£. 

1.2  Aims  of  the  Project  and  their  Relation  to  this  Report 

During  the  previous  years  of  the  project,  we  have  investigated 
some  new  principles  for  interconnecting  hosts  and  computer 
networks.  We  had  investigated  the  problems  of  connecting  the 
Rutherford  Laboratory  (RL)  IBM  360/195,  the  University  of 
London  Computer  Centre  (ULCC)  COC  6000/7000,  the  Royal  Signals 
and  Radar  Establishn'ont  (RSRE)  GEC  4080  and  the  Culham  ICL 
Systems  4/72,  onto  ARPANET  using  UCL  computers  as  the  front- 
ends.  While  all  tiie  individual  computers  nad  been  attached 
separately,  during  the  past  year  we  have  developed  a system  for 
connecting  all  of  them  simultaneously  onto  ARPANET  attached  to 
the  same  front-end  computer.  This  development  was  essentially 
completed  by  the  end  of  this  reporting  period.  In  Chapter  2 we 
discuss  how  the  UCL  system  has  developed  during  1976  as  regards 
hardware,  system  software  and  the  attac'nment  of  hosts.  The  work 
has  required  the  definition  of  a new  form  of  virtual  network 
connection  as  the  number  of  hosts  to  be  attached  grew  to  four. 

The  implementation  of  the  new  system  called  SWITCH,  is  discussed 
in  Chapter  3. 
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Ti\e  logical  next  step  was  zo  investigate  the  problems  of 
interconnecting  networks.  Here  we  had  analysed  during  the  previous 
period  the  facilities  required  in  gateways  between  networks  and 
had  started  implementing  a connection  to  another  specific  network, 
the  UK  Post  Office  (PO)  Experimental  Packet  Switched  Service  (EPSS) 
(Broomfield, 1975) . There  have  been  significant  changes  in  the  last 
year  due  to  the  acceptance  of  X25  (CCITT,1976)  as  an  agreed  standard 
interface  for  access  to  PTT  networks.  This  is  a virtual  call  network, 
which  can  be  used  with  some  modification  for  interconnection  of 
networks.  Our  general  approach  is  in  fact  a virtual  call  mapping, 
and  so  is  compatible  with  this  standard.  Our  approach  to  the  provision 
of  services  through  concatenated  networks  is  developed  further  in 
Chapter  4. 

One  approach  to  communication  between  hosts  on  different  networks 
is  the  implementation  of  software  to  a common  interface  standard.  We 
have  investigated  a specific  protocol  (TCP)  designed  for  communicating 
between  such  hosts.  These  experiments,  which  have  involved  both 
Stanford  University  and  Bolt, Beranek  and  Newman  are  discussed  in  some 
detail  in  Chapter  5.  We  have  completed  quantitative  experiments,  and 
have  also  simulated  some  modifications  which  have  been  suggested  to 
improve  the  performance  of  systems  using  the  protocol. 

During  the  past  year  we  have  become  increasingly  involved  with 
EPSS.  An  experimental  interconnection  between  EPSS  and  ARPANET  has 
been  devised,  with  one  PDP9  performing  mappings  between  ARPANET  and 
EPSS  protocols.  The  present  UCL  system  is  not  too  advanced;  it  performs 
3 EPSS  m.appings  at  a very  lov/  level,  which  does  not  use  EPSS 
efficiently.  However,  this  was  the  connection  first  adopted  by  RL,  and 
it  has  allowed  us  to  get  some  experience  with  the  problems  of  using  EPSS. 
Vie  are  now  running  experimental  sessions  for  UCL  users  of  the  RL  360/195 
using  the  ARPANET,  EPSS  and  the  UCL  gateway.  This  development  will 
be  extended  considerably  during  1977,  when  mapping  of  the  higher 
level  EPSS  protocols  will  be  achieved.  This  work  on  EPSS  is  discussed 
in  Chapter  6. 
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Althouyh  an  important  new  project,  the  AtLant-ii^  PacKet  Satellire 
Project  (PSP)  started  in  1975,  our  practical  involvement  in  the 
experimental  programs  began  only  in  1976.  During  this  period  a 
gateway  computer  was  installed  in  University  College  London.  We 
began  implementing  tools  to  generate  traffic  across  the  packet 
satellite  network,  to  control  the  experiments  and  to  collect  data 
flowing  between  the  gateway  computers.  Our  activities  in  this 
area  are  discussed  in  Chapter  7. 

A key  component  of  the  UCL  activities  has  been  very  extensive 
network  measurements.  In  the  previous  annual  report  we  discussed  our 
tools  for  access  control  and  measuring  terminal  access  control  through 
the  public  switched  telephone  network  (PSTN).  During  the  past  year, 
these  tools  have  been  developed  further  and  fairly  extensive  and 
varied  measurements  have  been  made  and  analysed,  although  PSTh 
monitoring  has  been  restricted  by  shortage  of  computer  tim.e.  We 
have  complete  records  of  all  traffic  using  the  UCL/RL  link  in  eit’ner 
direction  w/ionever  the  RL  machine  has  been  connected  to  ARPANET. 

The  information  is  output  on  paper  tape  and  has  been  kept  since  the 
beginning  of  the  UCL  ARPANET  project,  although  it  was  not  possible 
to  analyse  it  until  1976.  Another  form  of  measurement  that  was 
taken  during  the  year  was  that  of  line  traffic  passing  between  IMPS; 
this  has  been  carried  out  in  conjunction  with  the  experiments  on 
end-to-end  protocols  and  has  clarified  our  understanding  of  which 
performance  problems  depended  on  host-host  interactions  and  which 
on  the  interface  between  host  and  data  network  operations.  Finally, 
some  measurements  have  been  made  on  the  actual  performance  of  different 
network  control  programs  themselves.  All  the  above  projects  are 
described  in  some  detail  in  Chapter  8. 

The  UCL  node  has  been  almost  unique  on  ARPTiNET  in  that  it  has  a 
very  wide  spectrum  of  users  both  in  the  UK  and  the  US.  It  is 
possible  to  identify  the  user  community  fairly  clearly  because  of  the 
operational  rules  set  up  at  the  beginning  of  the  project  (see  Chapter  2 
of  Kirstein , 1 976a) , under  which  any  UK  user  must  obtain  explicit 
authorisation  from  the  Governing  Committee  of  the  project.  Similarly, 
every  US  user  of  the  UCL  node  must  obtain  explicit  permission  from 
ARPA.  As  a result  of  these  authorisation  procedures,  it  is  possible 


to  kri'jw  fairly  accurately,  who  hau  been  using  tht*  ra'f./ork  and  for 
w'hac  purpose.  We  nave  carefully  evaluated  the  usage  made  by  the 
different  projects,  most  of  which  are  col  i aborat  ivc  betv/een  the  US 
and  UK  groups.  This  usage  has  been  analysed  in  Chapter  9. 

Early  we  became  interesned  in  the  use  of  facsimile  techniques  over 
packet  switched  networks  md  a specific  grant  in  tins  area  (BL 
Grant  SI-G-121)  started  in  January  1976.  Our  .ictivities  in  this 
area  are  discussed  in  Chapter  10.  Tncy  include  the  con.iectior.  of 
a microprocessor  to  a facsimile  terminal,  its  connection  tc% 

ARPANET,  and  the  integration  of  facsimile  traffic  with  message  services. 

I 

The  conclusions  which  can  he  drawn  from  ctie  UCL  work  are  disv^ussed 

I 

I in  Chapter  11. 

j 

In  Appendices  A and  B,  we  list  all  the  active  and  non-active  research 
groups  who  nave  been  authorised  to  use  ARPANET  from  the  UK  during  1976. 
In  Appendix  C,  we  list  the  papers  .ind  presentations  made  by  the  group. 

1.3  Institutional  Arrangements 


The  institutional  arr.ingca.ents  described  in  Chapter  J of  (Kirstein,  1 ‘■i".- 
continued  almost  unchanged  dur,.ng  the  year.  The  PO  continued  its 
representation  on  the  Governing  Committee  with  one  representative  from, 
the  External  Communication  Executive  (ETE ,Letford) , and  one  from 
Network  Planning  (NP,  Broo.mf  Lold)  . The  direct  representation  of 
ETE  on  the  Governing  Committee  has  made  it  possible  to  discuss  more 
' directly  the  policy  and  the  practical  problems  raised  by  the  project; 

thus  it  is  possible  to  resolve  quickly  which  uses  of  ARPANET  from  the 
UK  are  permissible.  Several  applications  were  refused  which  involved 
f use  of  ARPANET  by  people  not  resident  in  the  UK,  or  in  which  the 

I principal  u.iage  would  have  been  for  message  traffic.  It  has  also 

' been  possible  to  discuss  frankly  the  criteria  which  will  be  adopte  . 

J during  1977  when  another  coimmercial  .service  is  expected  to  become 

I operational  between  the  US  and  the  UK.  .As  a matter  of  policy,  any 

j user.s  wfio  coiicc’ i vab iy  could  use  a commercial  service  will  not  be 

permitted  to  continue  their  use  of  the  ARPANET  link. 
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CHAPTER  2:  UCL  SYSTEVS  DKV2 LO:m.-.;-.T 


2.1  Introaaction 

The  UCL  development  has  always  been  significantly  different  from 
other  ARPANET  host  sites.  We  have  never  had  a significant  host 
ourselves,  but  have  served  as  a remote  front-end  computer  to  other 
hosts,  and  as  a gateway  to  other  networi<s.  This  role  has  made 
increasing  demands  on  tne  UCL  system  software  with  the  increase 
of  the  number  of  remote  systems  wnicn  wo  nai'e  attached.  In  Section 

2.2  we  show  how  ihe  system  has  developed  in  the  last  year.  'Fwo 
rem.ote  hosts  are  now  permanently  ava  i lab  le,  f.;;e  Rutherford  Laboratory 
IBM  360/1^^5  and  tr.e  Royal  Signals  and  Radar  Es"-  n-l is hm.ent  GEC  4080; 
two  more  hosts  are  attached  experi.menta  i.  ly , the  University  of 
London  Computer  Centre  CDC  6000/7000  and  the  Culham  ICL  System  4/72. 

The  attachment  of  iheso  hosts  is  described  in  Sections  2.4  - 2.7. 

The  initial  nost  attachment  used  somewhat  ad  hoc  software  in  the 
UCL  PDP9s,  m.iipping  from  .M<PANET  protocols  to  ones  desired  by  the 
target  computer  (Strkea,  197'’0  - The  amount  of  software  required 

is  significar.*- , and  w.  nave  Dei.n  very  concerned  to  improve  its 
performance  as  more  hos~s  become  attached  th.rough  the  sam.e  front-end. 
As  a means  to  improve  performance,  we  h.ave  made  consistent  measure- 
ments of  t’,e  PDP9  software,  and  changes  to  the  operating  system 
and  comraur icat ion  casks.  This  activity  is  discussed  in  Section  2.3. 

There  h.as  L>eon  a further  systems  activity  wnich  is  treated  in  a 
separate  Chapt-.  . This  is  the  complete  redesign  of  the  front-end 
philosopny;  now  a system- independent  set  of  interface  procedures 
are  defined  for  both  interactive  and  batch  traffic,  and  all  remote 
systems  protocols  are  maoped  onto  these  universal  ones.  While  the 
developm,ent  of  this  system,  called  SWITCH,  is  discussed  in  Chapter 
3,  the  progress  made  in  intergrating  the  host  software  to  run  under 
the  SWITCH  system;  is  discussed  in  this  chapter. 

2.2  The  UCL  Configuration 

During  1976  there  has  been  considerable  development  in  the  UCL 
configuration.  One  important  change  was  the  move  of  our 
group  from  Gordon  Square  into  the  new  Gower  Street  premises.  This 
move  required  tne  construction  of  a duplicate  post  office  facility 
and  the  move  of  all  the  group's  computers.  This  move  was  achieved 


rsiativoiy  painlessly  during  Ju^y  and  August  1976.  The  TIP  was 
moved  with  miniinurri  disturbance  and  was  only  off  the  air  for  cibout 
48  hours.  The  movement  of  one  of  the  UCL  PDP9s  was  also  fairly 
straightforward,  with  an  unavailability  of  only  about  1 week. 

The  second  UCL  PDP9  became  somewhat  damaged  in  transit  and  gave 
considerable  trouble  over  a five  week  period. 


The  difficulty  of  reconciling  our  research  and  service  commit-- 
ments  with  only  one  PDP9 , forced  us  to  reduce  the  availability 
of  the  RL  and  RSRL  machines  during  this  period.  This  resulted  in 
a substantial  reduction  of  usage  of  these  two  machines  - far 
sharper  than  would  result  from  a proportional  reduction  with  hours 
of  prime  time  availability.  This  brought  home  to  us  again  the 
need  to  provide  as  near  24-hour  availability  as  possible  for  any 
hosts  offering  services.  A third  computer  (a  PDPll)  to  act  as  a 
gateway  between  the  packet  satellite  network  SATNET  and  ARPANET 
was  installed  also  in  early  July  and  was  moved  with  little  difficulty. 
During  the  construction  of  the  duplicate  comjn."nication  facility, 
a number  of  changes  were  made  i.n  the  UCL  communication  equipment. 

The  configuration  at  the  end  of  1976  is  shown  in  Fig.  2.1.  The 
main  changes  over  tne  previous  y^ear  are  that  the  SATNET  gateway 
PDPll  was  installed  so  that  the  TIP  has  now  no  room  for  any 
further  hosts.  The  Computer  Aided  Design  Centre  Atlas  connection 
was  removed,  mainly  because  the  Atlas  itself  was  going  out  of  service. 
The  RL  and  RSRE  computers  were  attached  to  PDP9A  and  were  in  almost 
continual  service  throughout  the  year.  The  ULCC,  Culham  and  EPSS 
activities  remained  experimental  throughout  the  year  and  were  there- 
fore attachea  to  PDP9B.  Although  it  is  not  obvious  from  the 
detail  given  in  Fig.  2.1,  we  also  extended  our  communication 
equipment  so  that  PDP9A  and  PDP9B  have  essentially  identical 
facilities. 

The  number  of  terminals  on  the  public  switched  telephone  network 
was  reduced.  One  of  our  major  user  projects,  an  experiment  of 
MEDLINE  access  under  British  Library  auspices,  was  terminated  during 
the  year.  Our  network  measurements  indicated  that  the  reduction 
of  ports  on  the  PSTN  woulci  reduce  costs  with  a negligible  impact 
on  port  availability  to  users.  .Moreover,  the  usage  of  ARPANET 
through  the  RL  hosts  increased  considerably.  Finally,  we  wished 
to  start  coming  into  a position  under  which  terminal  access  would 
be  supported  mainly  through  EPSS.  For  these  reasons  we  reduced 
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s iqn if icantly  the  number  of  terminal  ports  offered  on  the  public 
switched  telephone  network. 

2.3  Operating  System  Measurement  and  Improvement 

To  support  our  communications  software  and  its  development,  we 
have  our  own  operating  system  for  the  PDP9 . During  the  year  we 
have  devoted  some  effort  to  a consideration  of  the  efficiency  of 
the  resident  sections  of  this  operating  system  and  its  core  alloca- 
tion, segment  loading,  segment  deletion  and  task  scheduling  func- 
tions. There  has  been  little  change  to  the  input/output  functions: 
drivers  have  been  added  for  new  devices  as  necessary,  and  extra 
queueing  was  provided  to  permit  synchronous  running  of  asynchronous 
format  character  devices  at  medium  speeds. 

A study  by  an  MSc  student  in  1975  of  the  ARPANET- RL  system 
running  at  that  time  suggested  that  marked  degradation  would  occur 
if  core  space  were  reduced.  As  a result  of  this  work  and  some 
theoretical  notes  (Hinchley , j 976A  and  Higginson , 19 76F)  on  segment 
loading  overheads  and  their  effects,  an  MSc  project  was  commissioned 
in  1976  to  investigate  the  current  segment  loading  and  core 
allocation  ard  delf^tion  algorithms,  and  to  develop  new  algorithms 
as  appropriate. 

The  report  (Johnson,  1976)  describes  the  extensive  measurements 
of  various  types  of  user  systems  (including  the  ARPANET-RL 
real  time  system)  in  normal  situations  and  with  varying  degrees 
of  coie  restriction.  The  object  of  running  core-restricted 
systems  is  to  simulate  the  effectsof  a larger  system  (ie.  the 
multi-machine  system.)  in  the  full  core  size.  The  results  showed 
that : 

(i)  The  segment  deletion  algorithm  could  be  improved. 

(ii)  Design  of  user  system  structures  could  be  improved  to  lessen 
operating  system  overheads 

(iii)  The  segment  loading  times  measured  were  a third  higher  than 
predicted  in  the  theoretical  notes 

(iv)  Two  specific  features  of  internal  operation  of  the  operating 


system  were  adding  largely  unnecessary  overheads 
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Correction  of  the  last  of  these  is  trivial  now  they  have  been 
isolated.  As  part  of  improving  segment  deletion  (which  is 
the  way  the  operating  system  regains  core  space  for  current  activ- 
ities) , the  core  allocation  routines  were  rewritten.  This  was 
also  necessary  because  of  known  flaws  in  the  current  allocation 
routines.  A system  incorporating  the  new  routines  will  be  tested 
during  the  first  quarter  of  1977.  Results  (ii)  and  (iii)  will 
be  studied  further  in  1977. 

It  also  became  apparent  during  1976  that  the  operational 
task-scheduling  routine  was  not  as  efficient  as  it  might  be, 
and  a long  term  solution  to  this  problem  is  being  studied.  However, 
two  'stop  gap'  measures  have  been  introduced  to  increase  the 
efficiency  of  the  current  methods.  Most  tasks  in  the  system  loop 
on  the  100ms  clocK  while  waiting  for  work  to  do^and  this  meant  that 
an  average  50ms  delay  was  encountered  when  work  became  available. 

The  clock  interval  was  redefined  tc  be  the  minimum  of  IDO  ms  real 
time  and  1 rr-s  idle  time,  thereby  reducing  the  normal  average  delay 
to  0 . 5 mg  but  not  overloading  the  system  with  unproductive  looping 
if  it  had  other  work  to  do.  Another  long  term  problem  is  the  non- 

reentrancy  of  PDP9  code  ; , in  particular  this  has  limited  access  to 
global  variables  and  intersegment  calls  in  such  a way  that  the  normal 
method  of  building  a system  is  to  define  a 'main  task'  which  does 
most  of  the  work  and  only  use  independent  tasks  in  a special  situa- 
tions within  totally  resident  code.  'Serially  re-useable' 
global  access  and  intersegment  call  code  has  now  been  developed^  and 
is  to  be  added  to  the  multi-machine  system. 

We  do  not  regard  further  systems  development  of  the  PDP9  as  a 
research  activity,  and  will  devote  as  little  further  effort  in 
this  direction  as  possible.  However,  it  is  clear  that  the 
multi-machine  configuration  of  this  chapter  will  make  new  demands 
on  the  capabilities  of  the  PDP9s.  Our  efforts  will  be  limited 
to  those  items  which  are  necessary  to  the  system  succeeding  in 
its  new  role. 

2.4  The  Attachment  of  the  Rutherford  Laboratory  IBM  360/195 

During  1976  there  has  been  almost  no  change  in  the  operational  soft- 
ware for  the  connection  of  the  Rutherford  Laboratory  computer  to 
ARPANET.  The  Help  facilities  and  PDP9  response  messages  to  users 
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on  ARPANET  have  improved,  and  both  the  facilities  for  and  extent 

of  csaqe  of  the  RL  system  have  increased.  Various 

specific  problems  in  the  file  transfer  area  were  also  remedied. 

For  example,  the  response  time  was  improved  by  using  system  level 
priority  in  the  360,  and  premature  timeout  of  long  connection 
periods  was  eradicated;  this  had  arisen  during  the  transfer  of 
very  large  files  and  output  from  submitted  jobs. 

.A  najor  effort  nas  gone  into  developing  a new  version  of  the 
ARPANET/360  software  to  run  under  SWITCH  (Section  3).  This  has 
had  three  components.  First,  it  has  been  necessary  to  solit  the 
ARPANET  Network  Control  Program  (NCP) /360  package  in  such  a way 
that  there  are  very  distinct  components  interfacinq  between  ARPANET 
and  SWITCH.  Second,  a 360  HASP  component  has  had  to  be  inter- 
faced between  SWITCH  and  the  HASP  interactive  terminal  drivers. 

Third,  it  has  been  necessary  to  break  up  the  file  transfer  protocol 

module  into  similar  parts.  One  connection  is  between  the  SWITCH 

FTP  package  and  the  ARPANET  NCP.  The  second,  goes  between 

SWITCH  and  FTP  and  a iiASP  RJE  package.  Since  very  similar  exercises 

have  been  required  for  all  the  other  computers  attached  to  the 

UCL  PDP9 , block  diagrams  of  the  changes  which  have  been  required  in 

the  ARPANET/360  software  are  given  in  Section  3.2. 

All  tnis  softv;are,  with  the  exception  of  that  required  for  file 
tra.nsfer,  has  been  written  and  largely  commissioned.  Most  of  that 
required  for  file  transfer  has  also  been  written. 

We  have  taken  the  opportunity  to  provide  much  better  status 
information  to  remote  users  on  tne  file  transfer  operations. 

Although  this  software  is  not  as  advanced  as  the  interactive  terminal 
parts,  we  anticipate  it  v/ill  aiso  bo  installed  on  the  operational 
system  by  the  end  of  the  first  quarter  of  1977. 

2.5  The  Attachment  of  the  Royal  Signals  and  Radar  Establishment 
GEC  4080 


Ine  Kcr'iL  .ind  R..ular  Establ  ishmc'nt  (RSRE)  GEC  4080  was  con- 

nected in  early  1976  to  ARPANET  through  a PUP9 ; the  connection 
simulates  a cluster  of  several  interactive  terminals,  and  a very 
simple  protocol  is  used.  A course  was  run  successfully  by  the 
RSRE  staff  in  Washington,  with  US  Department  of  Defense  (DoD)  partici- 
pants, within  a week  of  tl.e  line  between  RSRE  and  UCL  coming 
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into  service.  At  that  time  the  connection  was  made  through 
PDP-9B  and  nine  ports  for  simultaneous  usage  v;ere  available.  After 
the  course  was  finished  the  software  anu  the  connection  were  inter- 
grated  into  the  system  running  on  PDP9A , so  that  although  the  n'u.mber 
of  ports  was  reduced  to  five  the  availability  went  up.  Since  that 
time  the  system  has  been  available  for  more  than  twenty  hours  a 
day  to  US  participants  in  the  US  DoD  High  Level  Language  Evaluation 
Project.  Her  Majesty  the  Queen  officially  opened  the  Link 
on  March  26  1976  by  sending  a welcoming  message  to  some  of  the  US 
participants  during  a visit  to  RSRE. 

The  operation  of  the  RSRE  link  during  1976  has  been  as  an 
addition  to  the  standard  RL/ARPANET  system;  however,  a further  version 
of  our  software  to  run  RSRE  as  a connection  under  SWITCH  has  been 
commiss ioned . We  forsee  no  problem  in  continuing  to  have  the 
RSRE  computer  available  when  we  go  o^’er  to  the  multi-machine  operation 
under  SWITCH  at  the  end  of  the  first  quarter  of  1977. 

2.6  The  Attachment  of  the  ULCC  CDC  6000/7000  Complex 

The  connection  from  UCL  to  the  University  of  London  Computer  Centre 
(ULCC)  is  a 2.4Kbps  line  terminating  on  their  CDC  6400  which  can 
access  the  CDC  6600  and  7600.  Currently  the  PDP9  simulates  four 
CDC  200  User  Terminals  (a  200UT  is  the  CDC  hardwired  RJE  terminal 
and  normally  consists  of  a card  reader,  line  printer,  and  display 
unit).  However,  the  PDP9  software  has  the  card  reader  and  the 
line  printer  permanently  disabled  on  three  of  the  four  simulated 
200UTs;  this  still  leaves  the  full  interactive  facilities  of  INTERCOM 
(CDCA)  available  to  users.  INTERCOM  is  the  portion  of  SCOPE,  the 
standard  CDC  operating  system,  which  deals  with  interactive  terminals 
The  fourth  simulated  200UT  is  reservedfor  file  transfer;  this 
uti lizes  a simulated  card  reader  and  line  printer.  The  PDP9  soft- 
ware is  part  of  the  multi-network  SWITCH  system  (see  Chapter  3). 

The  protocol  used  by  the  CDC  is  a simple  polling  one.  The  CDC 
640(;  acts  as  a master  and  cyclically  polls  the  four  200UT  slaves. 

The  simple  nature  of  the  protocol  is  due  to  the  fact  that  CDC  200UTs 
are  hardwired  devices  and  hence  no  more  intelligent  protocol  could 
be  used.  The  CDC  6400  sends  an  addressed  message  down  the  line 
which  is  decoded  by  the  software.  If  not  recognised,  the  message 
is  discarded.  Otherwise , the  software  responds  appropriately: 
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’ .•  ng  to  or  'i.ere  rs  ^ ijto*.  rurt.;<.r  det^xis  or.  z'r.e  s 

CuC  ii^OL'T  prot-ccci  xo  giver,  in  ) . 

, 

One  of  the  dr^-wbacks  with  this  protocol  io  t;;at  the  error  recovery  I 

is  poo?'.  There  is  no  explicxt  acknowlcdger.'.ent  for  tne  receipt  of  j 

good  data  at  the  CUC  6400.  A sxtaation  -an  arise  in  which  data  for  | 

transir.iss ion  from  t.he  PUP9  may  be  corrupted  by  software  or  store  ' 

failure.  The  protocol  is  suci.  that  the  6400  will  continually  re- 
quest trans.mission  ox  tne  data;  there  is  no  timeout  and  no  way  the  li 

CDC  6400  can  tell  the  200L'1‘  a'.C'ut  tne  ex'roneous  data.  The  CDC  6400 

determines  v/hich  torm.inals  to  poU  from  internal  tables.  These  ! 

tables  are  dynamic  in  that  the  frequency  of  polling  will  depend  on  'what  | 

nas  been  happen.ning  in  tiie  xmjr.edxate  past.  if  there  has  been  some  ] 

exchange  of  inform.ation  'witbin  the  terr.iinai  recently,  it  will  be  j 

polxed  quite  f requent  i'y ; once  the  terminal  has  sent  a message  that  lias  1 

I 

no  '..nf ormiatxcn  this  frequency  drops  sharply.  There  is  a further  state  ! 

wriere  the  6400  gets  no  response  from  the  terminal,  in  which  case  the  | 

frecuancy  of  polling  wxil'drop  even  further.  In  this  situation,  j 

w'nxch  is  the  one  prevailing  when  the  PDP9  system  is  started  up,  it  can 
take  up  to  4 minutes  to  get  everyti'J  ng  started. 

The  200bT  protocol  is  half-duplex  and  is  used  primarily  for  the 
submxssion  of  card-imaoe  dat.'i  to  CDC  mainframes  and  the  receipt  of  “ 

line  printer  output.  Messages  can  Jje  'up  to  1000  characters  long,  f 

not  includj.;ig  control  i.nf ormation,  a.nd  there  is  space  and  zero 
compression  in  lineprinter  data.  The  method  we  have  adopted,  out 
of  necessit  ..s  not  very  efficient  for  short  interactive  messages,  as  one 
of  tne  network  .measurements  projects,  takxng  measurements  between 
tne  PDP9  ana  uive  CDC  6400,  hcis  siiown  (Section  8.5).  For  short 

messages,  on  a 2.4Kbps  line  with  a single  connection,  it  was  possible  | 

1 ' 

to  send  only  13.5K  messagt^s  in  10.6  hours  - giving  a throughput  of  ; 

liSbps.  For  a 3-connection  run,  22K  messages  were  sent  xn  9.8  hours , 
giving  a thoughput  of  adout  24Cbps-  These  low  figures  are  caused 
by  the  overhead  in  the  CDC  protocol  (70  msModem  turnaround  time  because 
the  protocol  xs  hdlf-duplex,  three  out  of  evex'y  four  messages  are 

control).  A ii'uxxmum  throughput  of  375bps  shouxa  be  achievable  on  this  I 

connection,  given  tnat  they  are  no  retransmiss xons  and  that  the  6400 
is  a...ways  ready  to  accept  data.  The  px'otocoi  was  really  designed 
for  multi -drooped  interactive  terminals  (for  use  with  a controller 
w^ich  blocked  tue  data),  which  can  operate  at  only  about  2400bps,  so 
that  a maximumi  of  375bps  for  messages  of  this  length  is  not 
unreasonable. 
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By  the  end  of  the  reporting  period  the  CDC  machine  had  been 
interfaced  to  SWITCH  and  run  experimental ly . It  has  been  passed 
over  recently  to  the  staff  at  ULCC  for  testing  by  them  before  a 
public  service  is  attempted.  The  file  transfer  section  of  the 
CDC  SWITCH  and  ARPANET  programs  are  coded  but  not  yet  integrated, 

A full  service  including  file  transfer  is  scheduled  for  the  end 
of  the  first  quarter  of  1977. 

It  should  be  noted  that  all  the  CDC  software  has  been  designed 
to  run  under  SWITCH  in  the  multi-machine  environment.  The  public 
service  will  commence  only  when  the  complete  multi-machine  including 
RSRE,  RL  and  HLCC  are  available  for  very  substantial  periods  on 
the  same  PDP9 . 

2.7  The  Attachment  of  the  CULHAM  ICL  System  4/72 

Software  for  the  connection  of  the  Culham  ICL  System  4/72  was 
described  in  Section  3.6  of  (Kirstein , 1 976A)  . At  that  tir.e  it 
was  stated  that  for  terminal  access  a slight  modification  was 
implemented.  D’jring  the  past  year  the  system,  has  been  run  alm.ost 
without  a change  in  a stand-alone  version.  Progression  to  the 
multi-machine  system  is  straig hi- f crwaro . The  lower  level 
line  and  block  programs  were  converted  into  the  mode  required  by 
SWITCH  when  they  were  incorporated  into  the  current  system,  used 
for  testing.  The  interface  level  programs  being  used  are  still 
the  RL/ARPANET  ones,  and  we  are  waiting  for  the  RL  360  SWITCH  inter- 
face to  uecome  operational  before  we  generate  a version  of  those 
programs  for  use  by  the  Culham  system.  Since  the  latter  system, 
is  a modification  of  the  RL  system,  we  anticipate  very  little  delay 
before  Culham  is  also  available  on  the  mul t i -machine  system  once 
this  is  in  use  (i.e.  at  the  end  of  the  first  quarter  of  1977). 

In  (Kirstein  1976A),  we  mentioned  that  the  file  transfer  would 
probably  be  implemented  using  modification  of  the  EPSS  basic  file 
transfer  protocol.  However,  during  1976,  the  standardisation 
activities  by  the  PTTs  have  reached  such  a point  that  EPSS  is  clearly 
only  going  to  be  a transitionary  standard  • V'Jiile  we  ourselves 
are  continuing  actively  with  SPSS  participation  (see  Chapter  6)  ^ 
it  is  improbable  that  Culham  will  also  become  EPSS  participants. 


for  this  reiison  we  have  agreed,  to  iriuleraenc  file  transfer  i-. 

Calham  by  giving  them  access  to  SWITCH  - FTP  coni.iands;  this  wii: 
be  done  by  putting  the  appropriate  comir.ands  as  HAS?  records 
(Higginson  ,1976)  . The  design  for  SWITCH  FTP  was  delioerately 
made  sufficiently  flexibly  that  the  commands  to  that  program  could 
come  from  another  machine.  Partly  because  of  Culham's  progress  and 
partly  because  of  our  ow'n  system,  developmental  schedule,  it  is  un- 
liitGj-y  that  the  Culham  file  transfer  will  be  operational  before  tl^e 
end  of  the  second  quarter  of  1977. 
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CHAPTER  3:  SWITCH-  AS  A NETWORK  INTERFACE 


3.1  Introduction 

The  UCL  SWITCH  implementation  serves  both  to  map  virtual  calls 
between  networks,  and  as  a network  access  interface  by  which  hosts 
can  be  attached  to  networks  via  an  intermediary  computer.  The 
application  to  the  interconnection  of  networks  is  discussed  in  detail 
in  Chapter  4.  In  this  section  we  discuss  connection  of  hosts  by 
considering  both  interactive  terminal  level  of  access  and  bulk 
data  transfer  by  use  of  file  transfer  protocols.  The  host 
attachment  may  be  by  established  work-station  protocols  as  the 
360  HASP  station,  or  by  a specifically-designed  data  exchange 
mechanism.  Reasons  for  interposing  an  intermediary  computer  may 
vary.  The  additional  load  to  the  main  CPU  may  bo  too  great  for 
com.fort,  or  alternatively  the  core  occupied  by  full  network  protocols 
may  be  too  great.  More  frequently  the  problem  is  the  reluctance, 
with  good  reason,  of  the  systems  staff  to  provide,  and  later  mai.ntai.n, 
nev^  complex  software  modules  buried  deep  in  the  operating  system. 

There  is  a paradox  here.  One  reason  for  the  size  and  complexity  of 
the  host  protocol  is  the  intention  of  providing  a very  flexible 
network  interface  able  to  support  a variety  of  applications, 
offering  secure  message  delivery  with  sophisticated  end-to-end  flow 
control.  By  removing  the  protocol  support  into  a front-end  machine, 
invariably  some  of  the  flexibility  may  be  lost,  unless  the  front  end 
host  protocol  is  itself  made  of  equal  complexity.  It  is  a matter  of 
some  interest  then  as  to  whether  this  technique  of  host  attachment 
should  be  considered  the  norm,  or  whether  it  should  only  be  used 
in  specific  cases  as  mentioned  above.  In  some  ways  of  course,  there 
is  a trend  to  distribute  some  processing  capability  into  microprocessors 
attached  to  a main  processor,  and  sharing  store  with  it.  Even  in  this 
case,  we  are  interested  in  the  amount  to  which  networking  protocols  can 
be  contained  within  such  a microprocessor  function. 

At  UCL  we  have  experience  now  of  a manufacturer’s  full-duplex  protocol 
(IBM  HASP),  a manufacturer's  half-duplex  protocol  (200  UT) , and  two 
ad  hoc  asynchronous  protocols,  one  to  a mainframe  (GEC  4080),  and 
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the  other  to  a microprocessor  {INTEL8G80).  Oniy  the  IBM  360  is 
an  originator  of  terminal  users,  the  other  machines  are  providing 
a service  to  network  users.  The  indiv’idual  derails  of  rhese 
connections  is  described  in  Chapter  2,  and  much  of  the  initial 
experiences  in  attaching  the  IBM  360  to  ARPANET  were  described 
in  the  previous  annual  report  (Kirstein, 1976A) . 

3.2  Interactive  Terminal  Service 

Ail  the  connections  completed  at  UCL  have  been  at  the  terminal 
level  or  above.  Because  multiple  server  host  destinations  are 
supported  at  the  satie  time,  and  no  mechanism  exists  for  selective 
onward  addressing,  it  is  necessary  to  ask  network  users  to  identify 
the  destination  they  desire,  on  reaching  the  PDP9;  th.ey  are  not 
able  to  address  the  required  service  machine  directly  from,  their 
source  machine.  The  only'  possible  direct  method  v/ould  be  to 
designate  a particular  host  as  a particular  'host'  ser-'icc.  Additionally, 
an  explicit  request  for  connection  allows  password  control  on  connecticn 
which  is  necessary  in  some  of  the  connections  which  we  support. 

3.2.1  Message  or  Character  Terminal  Service 

In  general,  we  are  catering  for  use  through  .ARPANET,  where  character 
terminal  access  is  the  norm  and  where  there  is  remote  echoing  of 
each  character  from  the  host  to  the  terniinal.  While  many  Tenex 
services  are  orientated  to  this  approach,  the  IBM  360,  for  example, 
operates  on  a line-at-a-time  basis.  For  users  of  the  360,  the  PDP5 
provides  echoing  so  the  terminal  user  sees  the  kind  of  echo  he  would 
expect,  although  only  complete  lines  are  being  forwarded  to  the  360. 

In  the  reverse  direction  things  arc  .more  complicated,  a user  attached 
to  the  360  would  like  control  characters  forwarded  to  the  net, 
v/ithout  carriage  returns  - the  addition  of  a carriage  return  would  be 
treated  as  a following  control  character  itself.  The  convention  has 
been  adopted  that  a 'line'  from,  the  360  terminating  in  a space  is  in 
fact  a partial  line  of  control  characters,  and  is  sent  out  into  the 
net  without  carriage  returns.  This  is  a reasonably  pragmatic  way 
of  solving  the  problem.  Some  more  elegant  way  of  providing  this 
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ability  would  be  useful.  In  future  networks^  remote  echoinq  is  likely 
to  be  replaced  oy  echoiny  at  the  local  torniinai  concentrator/network 
access  point  (Higginson,  1976D)  . This  PAD  (packet  asscmbler/d 
assembler)  approach  carries  with  it  the  implications  of  a page-mode 
terminal,  rather  thar.  a duplex  char acter-by-character  terminal 
access  such  as  Tenex.  . Use  of  hosts  such  as  the  360  is  made  easier 
by  this  approach  - the  burden  of  other  than  1 ine-at -a-time  handling 
is  too  much  for  most  networks  of  hosts  to  bear!  It  remains  to  be 
seen  whether  the  loss  of  cliaracter  access  will  represent  a large 
burden  to  bear. 

In  the  current  set-up,  360  users  into  ARPANET  see  both  local  and 
remote  echoing.  It  is  rather  difficult  in  front-end  situations  to 
got  exactly  the  right  balance  of  facilities.  Character-set  mapping 
is  another  thorny  area.  The  ULCC  6400,  for  e.xample,  only  has  a 64 
character  set  access  through  200  UT  protocols.  Genuine  U200  terminals 
Support  two  local  hardwired  control  characters  for  deletion  of 
characters  or  lines.  Use  of  the  CDC  6400  itself  does  not  require 
control  characters.  There  is  no  way  we  can  support  the  U200  control 
characters  easily  without  changing  TELNET  conventions  for  each 
ARPANET  access  depending  on  stated  destination!  This  would  mean 
cnanging  these  conventions  actually  during  the  exchanges  with  the 
user.  This  is  complex  due  to  our  multiplexed  connections  of  computers, 
but  would  not  be  too  unreasonable  in  a normal  situation  whore  only 
one  host  is  being  front-ended  at  a time.  We  have  recently  changed 
our  default  TEI.NET  convention  to  support  two  or  three  editing  characters 
and  to  allow  all  other  characters  to  bo  passed  through.  For  the 
ULCC  machine,  of  course,  this  just  means  that  control  characters 
need  supression  before  reaching  the  ULCC. 

3.2.2  A Single  Service  Level 

The  terminal- level  mapping  is  close  to  a transparent  m.apping  - 
especially^ as  in  our  case,  most  control  characters  are  passed  straight 
through,  and  we  are  not  supporting  some  of  the  more  sophisticated 
options  of  the  ARPANET  TELNET  protocol.  The  difference  is 
sufficiently  small  to  enable  us  to  implement  file  transfer  protocols 
(described  in  3.3),  which  use  the  interactive  terminal  mapping 
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3oit.ware  as  a binary  aara  path.  The  INTEL  SOoO  connect  Lon 
also  intended  at  least  in  part  for  binary  dati  tr ansraissiTm , 
although  in  this  case  not  by  a formalised  file  transfei'  protocol 
(see  Chapter  10).  It  appears  that  a common  service  level  at  the 
call-level  would  be  more  appropriate  to  all  current  applications, 
with  some  form  of  convention  for  terminal  protocol  mappi.ng  where 
appropriate.  Whether  this  option  could  be  automatic,  or  whether 
it  needs  option  commands  to  the  PDP9,  is  open  .it  tne  moment.  Our 
internetworking  experiences  (Chapter  4)  also  point  to  a ca'l- 
lev'el  of  mapping  as  the  best  service  base  to  use. 

3.2.3  Flow  Control 

Adoption  of  an  ad  noc  protocol  for  transmission  between  the  PDP9  and 
tne  INTSL&030,  for  instance,  has  forced  the  imposition  of  a simple 
orotccoi  for  this  connection.  Even  the  RL  160  does  not  iiave 
proper  flew  control  in  both  directions.  Across  SWITCii,  no  flow 
control  exists  currently,  use  being  made  of  backing  store  resiarces 
to  prevent  congestion.  Flow  control,  based  on  fne  volume  of  data 
currently  held  on  the  PDP9  in  transit  for  any  particular  connection 
would  be  useful  here. 

3.3  File  Transfer  Service 


The  implementat  ior.  of  an  ARPANET  interactive  file  transfi_-r  service 
to  the  RL  IBM  3t0  has  been  detailed  in  previous  ..mnuai  reports, 
and  in  published  papers.  During  1976,  we  wished  to  draw  this 
file  transfer  service  inside  the  framework  of  a general  file 
transfer  approach.  DecicLons  on  tne  nature  of  this  geneial  SWITCii 
file  transfer  protocol  wnre  based  mainly  on  internetworking 
considerations  end  .ire  discussed  in  some  detail  in  Section  4.3. 

However,  to  date  it  is  the  ULCC  6400  and  I<L  360  wjiicii  are  furt..est 
idvancod  in  interfacing  to  the  general  standard  adopted,  so  it  is 
appropriate  to  discuss  those  in  more  detail  here.  This  file  transfer 
protocol  IS  also  to  lie  used  for  the  connection  to  the  CFLiiAM  system, 
except  in  tnis  case  t'm  urotocol  v;ill  be  implementec  at  CULilAi'’. , wnoroas 
in  the  other  cases,  tne  protocol  is  being  mapp<.'d  respect  vely  into 
the  HASP  bulk  transfer  options  (+batch  job),  and  ti'.e  CDC  rudimentarv 
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fiie  transfer  option. 

Our  model  of  use  in  the  past  has  been  to  implement  a server 
file  transfer  only  where  the  request  for  the  transfer  is  initiated 
outside  the  PDP9,  say  in  ARPANET.  The  internal  file  transfer 
interface  makes  requests  for  a transfer  across  the  internal  interface 
Thus  requests  can  be  made  in  the  previous  way  by  mapping  the  ARPANET 
file  transfer  request  onto  the  internal  format,  or  by  introducing  a 
local  user  interactive  piece  of  software  able  to  formulate  file 
transfer  requests.  The  ARPANET  FTP  defines  a user  interface  to  its 
protocol;  in  the  first  instance  it  turns  out  to  be  more  convenient 
and  useful  to  implement  this  protocol,  and  map  it  onto  the  internal 
format . 

The  file  transfer  service  to  the  360  has  for  a long  time  been 
one  of  the  least  reliable  software  services  v;e  have  provided  . 

It  is  still  not  totally  clear  why  we  have  been  so  unsuccessful  in 
giving  a reliable  service.  Undoubtedly,  the  fact  that  the  360, 
although  looking  like  an  interactive  machine  (ELECTRIC)  is  fundamental 
batch,  and  the  file  transfer  approach  for  ARPANET  (and  the  new  PDP9 
interface)  is  fundamentally  interactive  lies^at  the  root  of  the 
problem. 

Moreover  file  transfer  docs  require  a level  of  service  of  higher 
reliability  than  interactive  use,  and  in  this  particular  service  we 
are  seeing  the  limits  of  the  front-end  approach,  or  at  least  our 
ability  to  write  code  which  is  satisfactory  for  this  situation.  It 
will  be  interesting  to  see  if  we  fare  better  on  the  ULCC  file  transfer 
scheduled  to  be  in  use  by  the  second  quarter  of  1977.  Certainly, 
this  time  we  are  devoting  as  much  software  effort  as  can  be  usefully 
employed  on  achieving  a reliable  connection.  The  CULHAM  plan, 
where  the  file  transfer  instructions  are  obeyed  at  their  site,  will 
also  be  a useful  pointer  as  to  where  the  weaknesses  of  the  approach 
lie.  The  prospects  of  job  transfer  protocols  for  networks  front- 
ended  in  this  way  are  not  high  unless  v/e  can  achieve  better  results 
than  so  far  indicated. 


A 
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The  File  Transter  Interface  in  Detail 

As  mentioned  earlier,  tne  SWITCH  FTP  uses  the  basic  data  transfer 
facilities  already  present  in  SWITCH.  SWITCH  addressing  can  also 
therefore  bo  used.  An  initial  request  is  made  to  the  destination 
FTP  service  using  a SWITCH  CONNECT.  This  facility  was  implemented 
with  a service  field  as  an  optional  parameter,  and  it  is  this  field 
which  is  used  to  indicate  S'!?  service.  Having  established  contact, 
the  data  connection  implicitly  set  up  is  reserved  for  later,  and  a 
buffer  passing  mecnanism  is  now  employed  as  a command  pathway  between 
the  two  FTP  modules.  Commands  use  an  8 bit  byte  as  the  basic  working 
quantity.  Commands  are  variable  lenqtii  option  strings,  and  replies 
to  a command  request  are  formulated  as  a new  commiand.  The  control 
thus  oscillates  between  tlie  two  FI’P  motlulcs,  but  new  command  requests 
do  not  have  to  bo  solicited.  In  most  cases , this  protocol  funtions 
within  the  PDP9  computer.  In  the  case  of  Cuiham,  it  is  planned  to 
operate  across  a communications  link;  then  collision  deadlock  situations 
may  occur,  and  must  bo  resolved. 

The  commands  available  include  the  following: 

INITIATE/ACCEPT  starts  a file  transfer.  After  completion 

of  exchang..  s of  options,  the  transfer  starts 
without  further  commands. 

ABORT  may  be  required.  It  can  be  signalled  from 

the  originator  or  destination  of  the  file. 

END  OF  DATA  AND 

FILE  STORED  are  the  messages  from  the  sender  and  receiver 

respectively  after  a successful  transfer. 

A substructure  of  commands  also  exists  mainly  to  deal  with 
initial  options  in  setting  up  the  transfer.  'I'he  possible  options 
include  whether  previous  versions  of  this  fileniime  in  the  destination 
directory  should  be  deleted  if  found,  whether  the  file  should  be 
appended  to  an  existing  file,  or  whether  the  file  should  be  treated  as 
a job  to  be  submitted  to  the  host  system  to  be  run. 


Specific  file  attributes  need  to  be  communicated  such  as  name. 


account,  p.issword  of  directory,  maximum  file  sixe,  and  maxir.'xr, 
record  lenqth  within  the  file.  The  flexibility  of  options  allows 
the  destination  to  refuse  the  transfer  if  it  is  unable  to  support 
the  required  feature.  The  ability  to  use  this  structure  for  .nRPANE 
IBM  360,  ULCC  6400  and  EPSS  will  be  under  investigation  in  early 
1977. 


CHAPTER  4; 


THE  INTERCONNECTION'  OF  COMPUTER  NETWORKS 


4 . 1 Survey  and  Background 

In  the  previous  annual  report  (Kirstein  ,1976A)  we  contrasted 
the  alternative  approaches  to  connectin'-]  nt.'tworks.  One  .ipprc.;o:h 
is  to  have  any  interconnecting  "gateway"  connected  to  each 
individual  network  so  tliey  can  continue  to  act  in  their  individual 
frameworks;  an  alternative  approach  is  to  ignore  any  helpful 
features  of  the  subnet  control  on  an  end-to-end  basis.  The  first 
approach  requires  complete  protocol  mapping  at  a gateway  but  little 
extra  protocol  in  each  host  to  permit  internetworking  - the  second 
approach  makes  little  demand  on  th.e  gateway,  but  requires  a strong 
end-to-end  protocol  in  each  host . 

Accordingly  we  pursued  research  objectives  on  both  fronts.  On 
the  one  hand  we  participated  in  the  joint  Stanford,  BBN,  UCL  program 
for  the  design,  development,  and  measurement  of  an  end-to-end 
protocol  (TCP-described  in  Chapter  5) , and  on  the  other  have 
constructed  a mapping  gateway-SW ITCH  described  later  in  this  chapter. 
This  mapping  of  virtual  calls  proved  a useful  technique  in  providing 
both  host  front-ending  and  terminal  support  of  network  access;  these 
areas  are  described  separately  in  Chapter  .1,  with  the  practical 
details  of  the  current  UCL  system  in  Chapter  2. 

During  1976  the  definition  of  the  X25  virtual  call  network 
interface  (CCITT, 1976)  and  its  adoption  by  the  major  PTTs  has  made 
a substantial  contribution  to  the  development  of  packet  switched 
networks.  It  has  aided  the  eventual  solution  to  the  problem  of 
the  interconnection  of  networks,  but  has  not,  by  itself,  provided 
the  total  solution.  In  1077  we  expect  to  make  use  of  the  lessons 
learned  from  both  'I'CP  and  the  map]iing  of  virtual  call  networks,  in 
achieving  an  internetworking  environment,  of  which  X25  is  a funda- 
mental constituent.  In  view  of  the  emergence  of  X2ii  as  a standard 
for  network  access,  we  will  review  briefly  our  current  attitudes, 
before  discussing  our  achievements  in  1076. 

Any  discussion  of  how  to  interconnect  networks  must  start  with 
how  the  individual  networks  are  built.  Here  the  PTTs  have  gone 
unanimously  for  a virtual  call  solution.  There  will  be  further 
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ai'«j jii'.enLs  put  rorward  by  dii'lerent  cjroups  wiiy  tru-y  ruiy  Ul'  vron-j 
(e.ij.  Pouzin,  197G)  , but  that  lu  not  our  concern  nere.  It  is 
important  to  stress,  however,  chat  X25  is  essentially  a Netwoict 
Access  protocol.  The  sender  is  provided  with  flow  control  and 
delivery  confirmation,  and  messages  are  delivered  in  sequence  - 
provided  the  network  is  completely  reliable.  It  is  not  difficult 
to  see  how  messages  couid  be  lost  or  duplicated  on  network 
malfunction,  so  that  users  will  still  probably  need  to  adopt  an 
end-to-end  protocol  (cl.  the  Bridging  Protocol  of  EPSS  users). 

This  may,  however,  be  comparatively  simple;  it  n<.-i.;d  only  guard 
against  tne  specific  failures  whicii  could  occur  in  X25  network 
failure.  Provided  some  of  tiie  modifications  proposed  (E.  g. Roberts  , 
1976)  are  adopted,  X25  is  also  suitable  for  ti.e  interconnection 
of  networks.  There  are  still  several  options  whic.h  need  agreement; 
some  details,  such  as  choice  by  the  data  terminal  equipment  of 
logical  link  number,  still  occur  in  the  areas  of  error  recovery 
and  status  reporting.  Wc  have  still  to  see  how  well  these  subjects 
are  treated  in  prsctical  implementation  of  single  networks,  to 
know  how  much  end-to-end  activity  will  be  required.  In  the  ca.se 
of  connected  gateways,  there  will  oe  new  problems  of  alternative 
routing  between  networks,  and  how  far  to  re-i'Stab  1 isii  call 
between  networks  wiuiout  call  interruption,  in  case  of  failures 
of  indiviauai  noues  or  gateways. 

'i'iiere  is  oni-  other  area  of  concern.  The  PTTs  regard  the  Public 
Switclieii  IXita  Xi'tworks  (PSD.X)  as  'their;;',  and  will  reserve  specific 
fieius  of  tne  packets,  for  example  the  address  field.  All  attac'-.- 
ment:;  to  f iie  PSDNs  arc  regarued  as  customers  with  lower  privi  le  dges . 
Often  over  the  next  decade  at  least,  very  substantial  nefworks 
will  rtwiuire  to  connect  to  the  PSDKs.  Their  operators  should, 
ideally,  bo  allowed  similar  access  to  reserved  fields;  otherwise 
it  will  be  necessary  to  set  up  yet  another  sot  of  protocols  to 
meet  tiiese  needs.  Exanipi.os  arc  facilities  for  addressing,  anr 
alternative  routing  to  several  gateways. 

Some  networks  will  not  be  appropriate  for  virtual  call  techniques 
in  tile  subnet.  Examples  are  those  where  the  predominant  traffic 
is  transaction  oriented,  or  where  there  are  large  rapid  f luctuatio.ns 
of  average  traffic  in  regions  of  the  network;  also  where  there  are 


rcquirenont.s  to  route  rioro  data  botweeti  tw„'  t-^rin lua  1 5 than  can 
reasonably  be  carried  on  one  route,  or  where  parts  of  the  networks 
may  be  liable  to  rapidly  \aryina  distrubance  sv’.ch  as  Packet  Radio. 
Because  of  such  specific  requirements,  and  of  compatibility  with 
existing  systems,  we  must  expect  that  a variety  of  types  of  networks 
will  exi.st  for  a substantial  period.  Moreover  there  will  continue 
to  be  a reciuirement  for  such  private  networks  to  interconnect 
with  PSDNs  and  with  eacVi  other. 

Fevi  networks  opeiato  on  pure  datagrams.  Usually  a datagram 
at  one  lov’d  becomes  a v'irtual  call  at  the  next.  UPSS  is  a 
network  ’providing  a virtual  call  interface  to  what  is  in  many  ways 
a datagram  subnet.  Conversely,  ARPANET  proviues  datagrams,  by  a 
complicated  virtual  call  mechanism  v.-hich  must  be  set  up  for  each 
and  every  datagram  (unless  the  interv’al  between  messages  on  the 
same  route  is  less  than  two  seconds)  . Thus  t iio  main  discus.sion 
seems  to  hinge  on  where  to  place  the  virtual  calls.  TRi^NSPAC  is 
planned  as  a pure  virtual  call  network. 

The  pure  "Datagram  Network"  school  bol'eves  the  datagrams 
should  be  retained  throuch.  the  v.'holo  subnetwork,  including  thc 
gatoways  in  cone,  m rn  >.  i od  networks.  'ITie  pure  "Virtual  Call" 
school  believe  Liu'  ca 1 1 s should  be  a fundamental  property  of  the 
subnetwork  and  hence  certainly  of  lire  i nterconnect  ing  gateways. 

An  interm.odi  ate  group  );.eliovcs  that  datagrams  arc  alright  for 
subnetworks,  but  that  virtual  call  are  re(;uired  for  the  interconn- 
ection of  network .s . 

As  v/e  have  already  discussed  our  attitude  to  concatenated 
virtual  call  subnetv;orks , we  will  now  discuss  those  operating  on 
concaten.-ited  datagrams.  More  exactly,  we  will  discuss  concatenated 
networks  where  i t is  inapjjropr  iate  to  make  any  assumptions  about 
delivery  orfior  , rcl  iability  or  dupl  ic<\t  ion . Tn  such  networks 
dynamic  re-routing,  mult  iple  gateways,  multifile  jiaths,  reconnection 
etc.,  arc  not  concoptual  ly  difficult  - but  strong  end-to-end 
protocols  arc  recfuirod.  Here  our  cf  torts  so  far  have  centred 
on  the  TCP.  Our  oxfieriences  to  date  arc  reiported  in  Chapter  5, 
and  h.ivc  not  been  too  jiromi  s i nej . Botti  the  TCP  of  Chapter  5 
and  the  b IN/CYCbADh'.h  station  firotoco]  ( Z immerman  , 1 9 7 need 
cfins  iderablc  resources  both  for  imiilementation , and  to  achieve 
hicfh  throutjhfiut  . 'ihese  end-to-end  jirotocols  function  best  over 


relatively  si.Tipie  networks.  Tne  need  to  superimpose  such  a protocc 
on  top  of  virtual  call  procedure,  leads  to  excessive  redundancy  xn 
checking  and  flow  control,  both  at  the  level  of  the  software 
needing  to  reside  in  the  host,  and  in  the  additional  header 
information  needed  to  be  carried  in  each  packet.  In  practice  UCL 
work  shows  a more  subti.e  and  unanticipated  problem;  the  end-to-end 
controls  can  be  sufficiently  "out -of-synchron i zation"  with  the 
lower-level  protocols  tnat  "protocol  interference"  results  fsee 
Chapter  5) . The  usual  network  symptoms  of  congestion  and  consequer 
performance  loss  may  be  expected  to  occur,  unless  some  controls 
are  added  at  and  between  gateways.  If  they  wish,  to  minimise  gross 
changes  in  traffic  rate  between  one  pair  of  terminals  due  to 
interfering  traffic  by  anotuer,  some  flow  control  is  required  on 
a "per  network"  or  even  "per  connection"  basis.  Thus  one  is 

easily  faced  again  with  virtual  call-type  flow  control  in  the 

gateways.  Moreover,  in  concatenated  n-'t works,  it  may  be  essential 
to  achieve  reliable  transmission  between  ijateways,  and  thus  to 
have  virtual  call  facilities  for  flow  control,  error  reporting, 
accounting  and  st^itus  informet.,on . 

In  view  of  the  above,  wo  believe  that  all  th>.'  following  areas 
need  further  work; 

1.  Procedures  for  connections  of  X25  nof/.forks  to  each  other, 
via  modif ications  of  X25 

2.  Connections  of  X25  networks  to  other  virtual  call  networks 

3.  Connection  of  virtual  call  non-X2S  netwoi'KS  to  each  otlier 

4.  Connection  of  virtual  call  networks  with  datagram  network.'^ 

5.  Interconnection  of  datagram  networks 


We  expect  to  do  reasonably  little  work  on  (1)  in  the  near  future; 
we  will  have  littie  access  to  several  such  networks,  interconnect. 
them  may  be  difficult  politically,  and  ti.e  PTTs  and  other  public 
bodies  arc  putting  considerable  effort  into  tr.is  area.  We  will 
watch  tlic  activities  of  others  in  this  area,  and  try  to  anticipate 
the  problems  in  interconnecting  "Public"  and  "Private"  X25  networks. 
We  expect  to  concentrate  on  (2),  (3)  and  (4)  and  on  variations 

of  (5)  where  the  connection  is  done  by  virtual  call  association 
techniques.  We  will  continually  bear  in  iViini.i  t!iat  virtual  call 
procedures  are  likely  to  move  towards  X25,  unless  good  reasons 
appear  to  the  contr.iry.  In  all  our  work  with  virtual  ca  1 1 networks. 
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wc  '.vili  concontrato  on  tlio  provision;'  oc  services  through  the 
networks.  There  has  been  little  standard isdtion  of  this  field, 
anc  tile  work  is  needed  as  nraeh  for  X2h  network;j  as  otiiers.  The 
wiioio  tenor  of  the  work  we  report  in  Section  4.2  and  Chapter  o 
IS  on  tliis  theme. 

In  Section  4.2  we  descriiic  our  vyorrc  in  197(->  in  the  mapping  cf 
virtual  call  services.  In  our  environment,  networks  with 
different  facilities  terminate  at  I’CL,;  .il  ,l  nave  a virtual  call 
eve  L . We  have  .level oped  geru  ial  syi^Lem  iviLIeo  SWITCH,  wnich 
allows  t.he  provision  i:f  interactive  terminal  facilities  through 
concatenated  networks  terminating  at  UCL  by  performing  protocol 
riiapplm^  in  tire  CCL  Gateway.  We  iiave  developed,  but  not  yet 
rorrmiiss  ioned , a furtl'.er  extension  by  which  bulk  transfer  services 
can  be  providcii  in  this  environment. 

In  Section  4.3  wo  surv''v  our  v;ork  durinp  I97b  on  strong  end-to- 
end  pr(.)tocols,  and  coi:mii.'nt.  on  its  extensions  ciurimi  igV''.  Finally, 
in  Section  4.4,  we  outline  ear  plan,  for  further  work  in  general 
in  tills  area. 

4.2  UCL  work  in  ina(<|'inc(  virtu..iL  ca  I 1 protocc.ils 
4.2.1  Introuuct ion 

During  1976  mucii  oi  tne  work  on  the  UCL  SWITCH,  a general 
mechanism  for  mapping  virtual  calls,  has  gone  into  providing  the 
front-endinq  ami  satellite  processor  functions  of  Chapters  2 and  5. 
Use  of  SWITCii  in  this  year  for  iiackct-sv/ltcheci  network  inter- 
connection has  been  for  ARl^ANKT-ARPANFT  map’pimis  and  in  preparation 
for  connection  of  Fl’SS  'I’O  ARI’AWFT.  Tiio  implemen  tat  ion  of  tlie  KPSS 
host  protocols  ticiiievod  in  re.uiiness  fur  interconnection  in  the 
first  (juarter  of  1977  is  descrilieii  in  Cliapter  L . 

Tiiere  arf  four  main  levels  iit  whithi  a inappimj  of  virtual  calls 
mi  gilt  take  place:-  at.  Uie  iiasic  level  of  trams  lating  each  control 
or  dat<i  packet  of  one  lU'twork  into  tlic'  .gipropr  i a t e control  or 
data  packet  of  the  other  net;  <it  the  level  of  tiic  call  itself  - 
the  main  primitives  of  tne  ca  Li  .iro  mapiied,  but  no  liircct  ono-for- 
one  mapping  takes  [iJace  on  each  control  sicj:iaJ;  at  the  level  of 
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interactive  terminals;  and  in  i a t . .vn  .-.iti.  t:.e  ire'.'i 'as 

method,  the  ma[i[)ituj  of  file  transfer  ; >1.  .)toea.' 1 r, . We  shall 
describe  in  Seel  ions  4.2.2  .aid  4 . .' . 3 tin  lieh.  ,SWi'i’>.‘!l  i nt  ei  ae  t i ve 
terminal  mappini]  and  SWITCh  file  transfer  mappiiu;  i i.'speeLi'.'cly . 
Mappiny  at  tiie  packet  level  lias  been  discuss>.!d  in  tiie  literature; 
a mapping  of  X2i>  and  L?SS  has  been  reviewed  at  'dCx^  ( H 1 y>- inson  , 1 9 '' 
but  not  specifically  in  an  i nternetv/orking  conte.xt.  Another 
recent  example  is  the  mapping  of  L'IN/CYCLADES  end-to-ena  pr-t>-cr_ 
into  X25.  In  general,  mapping  at  th.is  level  is  extremely  co.m, plex 
and  usually  asymmetric.  .Moreover  there  is  danger,  r.s  in  tl'.e 
CYCL.ADES/X2  5 case  proposed  by  IIASA  ( Sexton  , 1 ‘•'7m  ,,  , . -f  ecnfusi.ng 
the  roles  of  end-to-end  protocols  as  opposed  to  tiie  net'work 
access  interfaces  like  X25.  We  believe'  that  r.apptng  at  t.he 
virtual  call  level  is  the  most  ;ironising  approach  foi'  interconnec 
tliere  is  an  implication  that  users  wishing  to  crumr.un  i cat  i-  must 
implement  tiie  same  terminal  or  otiier  i.ghcr- 1 evel  protocols, 
it  does  not  follow  tliat  there  mast  be  univ'orsal  h if, ’her- 1 evel 
protocols;  even  in  ARPANET  tliere  are  closed  communities  of  hosts 
•which  obey  different  liigher-lovcl  protocols.  User  hosts  must  hav 
a common  reliable  virtual  call  facility,  or  alternatively  end-to- 
end  association  of  calls.  Users  of  network  services  will  essenti 
bo  closed  groups  in  many  instances.  It  ’would  be  unfortunate  and 
uneconomic  to  have  a multitude  of  incompatible  ’r. i glier- 1 evel 
protocols;  howi'ver,  complete  standardisation  at  that  level  is  not 
as  necessary  as  at  lower  level.  In  the-  situation  'we  will 

provide  varying  si'rvice  levw'ls  at  the  tjatt'way;  as  a beginning 
we  will  experiment  witii  a full  call  iiirippii ng  vn  t!ie  EPSS-.ARP.'oNT.T 
situation  (Cliapter  0)  by  mapping  virtual  terminal  protocols. 

'i'tie  mechanism  of  SWlT’dil  described  in  this  section  permits  the 
introduction  of  different  service  levels.  We  expect  to  oxperimen 
during  the  next  couple  of  years  with  different  types  of  mapping; 
for  this  a flexible  software  structure  in  the  Gatev/ay  is  a 
prerequisite . 

4.2.2  Interactive  SWITCH  Mapping 

The  principles  .aid  practice  of  the  SWPi'Gli  virtual  ca  1 1 .mapping 
software  nave  heeii  outlined  in  an  earlii'r  paper  ( Higg  inson  , 1 9 75i' ) 
revised  and  summarised  in  ( Ki rsLei n , 1 9 7GA ) , and  described  in 
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ir.pio.v.entat  L on- levo L detail  in  two  internal  notes  (liinciiley  , 19763 
and  C).  Vhe  SWITCH  conventions  distinguish  between  tlie  originator 
and  the  recipient  of  a virtual  call  request  (all  calls  are 
assumed  duplex) . A call  made  to  the  gateway  will  result  in  an 
ALLOCATE  request  to  a central  SWITCH  utility,  with  the  identity 
of  the  initiator  passed  to  SWITCH  also. The  address  of  the  destination 
IS  now  conveyed  in  a CONNECT  request  to  SWITCH.  SWITCH  will 
identify  the  destination  among  network (s)  currently  attached,  and 
itself  initiate  a call  out  to  that  destination  by  requesting  the 
host  software,  resident  also  on  the  gateway,  to  make  a call.  If 
the  call  is  successful,  it  is  allocated  a port  number  to  distinguis.h 
It  from  other  future  calls;  a similar  process  was  carried  out 
for  the  originator  on  contacting  SWITCH.  SVITTCH  thus  holds  the 
identity  of  two  virtual  calls,  such  that  data  originating  on 
either  call  can  be  forwarded  to  the  other,  by  means  of  Data  Pickup/ 
Data  Forward  requests  to  SWITCH.  App/ropriate  meciianisms  e.xist 
when  either  call  is  unsuccessful  to  inform  the  originator. 

In  order  to  realise  these  facilities,  not  only'  tiie  basic  Host 
but  also  the  Virtual  Terminal  Protocols  are  imple."iented  in  the 
Gateway  for  each  network.  By'  the  time  inessaiies  arrive  at  SWITCH 
they  are  ASCII  strings,  with  no  protocol  control  characters  contained. 
The  control  information  for  indicating  call  destination  and  error 
information  are  also  ASCII  strings.  Since  tb.e  strings  can  be 
originated  and  interpreted  by  a human  user,  interconnection  can 
be  achieved  without  any'  end-to-end  conventions  at  the  level  of 
software;  the  appropriate  commands  can  be  supplied  by  the  user. 

This  clioice  is  not  fundamental  to  the  implementation  but  greatly' 
eases  the  commissioning.  A basic  set  of  connection,  addressing, 
and  error  codes  could  be  devised  to  pass  on  this  information 
from  initiating  software  to  the  gateway,  and  if  necessary  bey’ond. 

Sucri  a set  of  codes  would  of  course  bo  essential  in  a pure  call 
mappi  mj  gateway;  such  a set,  togctlter  with  suitable  algorithms 
to  obey  when  connections  fa  i ■>  , will  also  be  a fundamental  necessity 
in  the  interconnection  of  X2I3  networks. 

1- igurc  4.1  shows  the  UCL  software  modules  used  to  provide  a 
mapping  between  EPSS  and  ARPANET.  The  central  SWITCH  section  is 
essentially  a sot  of  mapping  tables,  but  is  swelled  by  the  need 
to  keep  a rigorous  chock  on  orderly  establishment,  and  maintenance 
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of  tile  mapped  call.  To  this  end  SWITCH  desijruites  a number  of 
states  through  which  the  mapped  connection  can  be  expected  to 


ALLOCATE : 
OPENING: 


OPEN; 

CLOSING; 


DISCONNECT: 


an  originating  cail  has  identified  itself 
an  attempt  at  onward  connection  is  being 
made 

the  call  mapping  is  established 
a user  originating  signal  has  requested  the 
closing  of  tlie  call 

the  call  mapping  is  broken,  but  each 
contributing  call  must  be  siiut  down 
separately. 


The  final  phase  is  analogous  to  the  normal  establishment  of 
a virtual  call  in  the  network,  where  the  initial  call  request  is 
a simplex  path  to  a well-known  address  in  the  destination  iiost; 
only  v/hen  that  host  has  allocated  a suitable  unique  address  and 
communicated  it  back  to  the  originator,  can  a pure  duplex  path 
be  said  to  exist.  In  our  context,  the  initiation  of  the  call 
mapping  is  an  easy  stepwise  process,  with  clear  failure  conditions 
and  steps  to  be  taken  if  tlie  call  is  not  completed.  The  closing 
of  the  call  is  more  complicated;  when  one  side  signals  the  call 
closing,  each  .side  of  the  call  must  go  tlirough  an  independent 
disconnect  process.  In  SWITCH  it  happenec  that  independent  call 
records  (cross-linked)  are  maintained  for  each  call  mapping.  For 
the  duration  of  the  call,  much  of  the  information  is  duplicated, 
so  t!iat  a single  record  would  suffice;  at  one  stage  we  considered 
such  an  implerrientation  to  be  more  economical  on  core  store.  This 
disconnection  process,  however,  Involves  asynchronous  changes  in 
each  contributory  call,  which  are  in  no  way  linked;  here  the 
separate  call  records  are  essential. 


So  f<ir  we  have  had  no  operational  experience  between  ARPANET 
and  EPSS,  but  have  used  the  SWITCH  mechanism  extensively  for 
ARPANET-ARPANET  mapping.  As  described  in  Section  3,  this  Virtual 
Terminal  Interface  is  a convenient  vehicle  for  front-ending;  the 
entire  relevant  UCL  system  has  been  converted  to  a SWITCH  interface 
( see  Chapter  2 ) . 


One  of  the  nia^or  probieihs  experienced  iias  been  tiiat  the 
terminal  protocol  of  ARPANET  is  oriented  to  sinqle  characters. 

This  protocol,  designed  to  suit  DEC  machines,  allows  intimate 
character-by-character  exchanges  between  user  and  host;  in  some 
subsystems  one  can  type  a character,  and  the  host  will  fill  out 
the  remainder  of  the  word.  This  is  a very  pleasant  facility  to 
use,  but  when  in  addition,  the  basic  mode  of  use  is  to  let  the 
host  also  perform  all  character  echoing,  th.en  the  load  of  the 
network  in  very  short  packets  becomes  excessively  r.igh  and  the 
echo  delay  Long  (in  our  case  this  is  accentuated  duo  to  use  of 
a communications  satellite).  With  the  per-packot  tariffs  being 
introduced  by  the  PTTs,  this  mode  of  use  would  be  prohibitively 
expensive.  In  the  internetwork  environment  short  character 
packets  consume  particularly  large  gateway  resources;  it  is 
necessary  to  forward  each  packet  separately,  generating  the 
appropriate  acknowledgements  in  each  direction.  In  view  of 
the  possible  need  to  repackage  each  packet,  not  necessary  in  a 
homogeneous  network , the  processing  load  may  be  exhorbitant.  In 
fact  ARPANET  aid  design  a .new  terminal  protocol  with  local  echoing 
but  this  has  never  been  fully  implemented.  The  trend  ro  terminal 
controllers  handling  whole  lines  of  te.xt  (PADS  in  Euronet, 
Higginson, 1976D)  means  that  this  problem  will  not  recur  in  quite 
the  same  w.ay  with  other  networks. 

Flow  control  across  the  gateway  has  not  been  a problem  so  far, 
because  each  connection  across  tiie  gateway  is  mapped  into  internal, 
message  queues  wnich  are  automat ical ly  buffered  on  drum.  We 
hope  shortly  to  experiment  with  different  amounts  of  use  buffering 
on  packets  in  the  normal  storc-and- forward  capacity;  The  processor 
overhead  to  transfer  messages  to  and  from  backing  store  will 
become  excessive  as  our  requirements  in  the  gateway  increase  - 
but  removing  it  may  require  discarding  packets  which  could  cause 
yet  additional  delay.  On  experimenting  with  buffering,  we  will 
encounter  congestion  problems;  a suitable  flow  control  signalling 
across  t)ie  gateway  is  an  essential  constituent  of  the  design  of 
the  gateway  SWITCH  interface. 

Tlie  need  to  handle  networks  with  different  maximum  message 
lengths  has  not  yet  been  encountered  at  UCL  and  can  be  avoided 
in  an  interactive  terminal  mapping.  In  general,  iiowever,  fragmient 
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ation  will  be  needed  at  the  yateway  - inscance  for  an 

ARPANET  multi-packet  inessaqe  going  to  EPSS;  the  consequences  ot 
such  fragmentation  have  still  to  bo  examined.  In  the  Bridging 
protocols  of  EPSS  packet  Doundaries  are  not  rigid;  the  TCP  of 
Chapter  5,  being  a general  internetwork.!  ng  end-to-end  protocol, 
has  v^ery  flexible  built-in  f raymentation  facilities. 

4.2.3  SWITCH  File  Transfer  Mapping 

Tlie  more  we  move  away  from  the  communicat lons  level  cevs^ards 
computer  applications,  tlie  Less  ; ikeiy  wi?  aie  t;)  encount  er 
conventions  tliat  are  different  Ijut  yet  ei.;u  i .'i  Liui  t . File  tra.nsfer 
certainly  comes  into  tills  latter  category.  ...t  Invi.  Ives  a 
corrimunications  function,  but  is  specifiea  in  terms  ot  tne 
characteristics  of  the  file  residing  on  tiie  vir  ly  inat  iny  source 
of  the  file. 

There  is  a strong  need  to  attempt  to  map  file  transfers.  A 
file  transfer  service  is  an  essential  adjunct  to  an  interactive 
service,  and  is  the  basis  for  all  text-processing  use  of  networks. 
File  transfer  between  EPFb  and  .ARPANET  is  a necessary  condition 
to  support  any  real  internetworking  between  tnose  two  networks. 

We  have  been  considering  various  approaches  uo  providing  an 
internetv/ork  file  service.  None  has  been  implemented  yet,  but 
our  present  thinking  on  the  relevant  merits  of  each,  is  discussed 
below . 


We  have  considered  three  alternatives  (Higginson, 1976E)  for 
supporting  file  transfer  at  the  UCE  gateway  namely: 

The  implementation  of  EPSS  file  transfer  protocols  on  Tenex 

A direct  attempt  at  {.iroviding  a SWITCH-type  mapping  of  the 
in  i ti  at  ion /’fstabl  ishment , and  progression  of  the  file  transfer 

A centralised  FTP  controller  cajrtible  of  initiating  transfer 
of  the  file  onto  the  backing  store  of  the  gateway,  and  at 
some  later  stage  forwarding  the  file  to  the  host  on  the 
destination  network. 


The  EPSS  file  transfer  protocol  seeks  to  avoid  some  of  the 
pitfalls  of  ARlViNET  protocols,  althougli  no  user  experience  has 


yet  ooen  v,  i li,  il.  xr  is  es.,c;'.t  i ..  x • y utirv/t.  r/ - r.n . ; ' 

■ lUvi  pi'ovi.t:rs  a iifxiijxt.-  opt:ons  ±Lnt  and  cnf'CKUo  xnr  i nij  i 
cajJiib  li  ity . It  IK,  tiu.'rtioi't:- , - c?ocd  candidate  :or  v.':dx'r 

ayq- i ic.it  i on  (l^iN  arc^  .aiopt.  luj  a variant).  rurt!iornoi'> , .is 
qenx:-ral  nno  i.s  ctji.cent  r.;ted  on  IV'nex  i.iacndine.s , an 

ir;ip  lor, lent-.,;  L xo.i  oi  ti.e?  di'dd  prot:ox’ol  on  Tc'nex  c'oulc  bi  oi  otao  i ; 

chrouxjh  AKl'ANbT  'I'er.vx  nost.s  in  aucn  a way  .ns  to  provixii'  a 

re.Kson.ib Uj  borvice.  It  : .1  v.’ortJ.  notinq  of  eot.rse  that  i..'<  1 ; 
wishiiuj  to  trails!  t'T  CiLi.as  to  ''ui.sts  otlici'  t tuai'  Tenex  wou  ^ : no'-"-: 
to  ptirforin  two  succei.sivo  ti.irisfers,  roirictliinq  ar,xn  to  winit  wo 
could  do  aut-OX'i.it  i ca  ] 1 y with  a c:ent  la  l i sed  ri'i’  cc-ntr<  iler,  ar,; 
siiOjtly  u 1 scus.si'c.  in  n.uro  ik/t.-.il.  Is’o  fln.il  aeci-  i.j.'i  a.i:-.  been 
taken  on  v/l,t.a  hei  t(,  try  to  impl  eruint  t ;i  1 .s  .ippioan.,  nor  aar  tiie 
eftort  needext  t c>  .ichievx  .1  btatiiion  bx-ea  est  ir.tat  eri.  !t  ;i'Vivua’!\ 
involves  a luu.'Ji  iiajia'  1 nt  iii.,.t  c usl'  <->1  iVr.cx  ir.a  ch  1 ".i  tt..ii.  •in'  L\'L 
ijroup  nan  attciuptx'a  so  t>;r.  'ii;ia  subit'cl  1 ai.'^  •usac'a  arti'.'ar 
xn  Section  4.4.  In  Mx-nera  1 , if  we  ai.ii  to  detina  t iie  icvx''l  or 
ijateway  activity  sui  ii  t lia  t reaidraul  end-ti  -otid  iunctions  t ■■■iiie 

xn  iiosta,  then  e,i  t .i'--;  we  or  et  1 1 .tboi  atr  r n ::.uat  i,  ..rxparx—  t,  go 

those  implement  at  10ns . 

'I’no  secoiid  appro, ich,  .1  diix'ct  :..a{ipir.c  or  preLocels,  lepuires 
a relatively  simple  central  ■ i in,  fxiciiit.  , imic.*'.  ot  WM;-:n.  is 

requireu  .lii'eauy  1 ti  tAVITtlh.  .'xace  xxM.ipxe;:  1 1 i e transfer  1:"..  1 ..'rtarnt 
attorns  aie  also  require,.!  t,.'  m.aport  t!.e.s:.-i  : t ; ■ x'  ; r' 

particalar  xi  i rx'ct  ,.i ' ai . dx'  iiavx'  ,:ho.sxn  t>-  loilow  tiiis  p.ith,  , lui 

are  Wx-ii  Into  trur  xK'iinit  ton  tiapi, xxrux'nt.it  ion  tlie  nece.s.s.’i rv 

protixcois.  At  first  wx-  wr  1 1 ber  ter.tii.q  thesx'  protoc,'is  to 
suppoit  Lile  transfers  i ron t-euxtcd  to  hxists  sucii  as  tiu'*  Hb  .ba,' 
anu  tne  UbCC  CtiC  (>400;  t h , .1  is  .maUnjous  to  oui  initi.il  work  on 
SWITCH  itself.  Vv,'  expx'ct  to  liavx'  these  taev  titles  oper  atior.-i  1 
towards  tne  end  of  the  first  quarter  of  i977,  with  nPSS/ARPAN'HT 
file  transfer  later  in  tne  year. 


Before  descrioim;  some  of  tne  details  of  the  planned  tr.rile.T.c.nt 
ation  of  tne  rnappoa  transier,  we  will  comment  on  a centralised 
CxHi  t rol  1 er  . Here!  <i  user  i.acility  would  prot>.ibiy  be  i niji  1 er.entcd 
stich  tiiat  a file  Liansfx.-r  rxsiux'St  would  always  i>e  ma<ie  dirc'ct  rc, 
the  (jateway  or  anotm-r  internetwork  file  contiolier.  The  ■•tnntral 
fticility  Would  allow  simultaneous  transfers  across  tlie  »nitewav 


s'viiuabiO  for  intoraot  ive  I’.He,  but  uis  > v.\-ui  ; .i^. » utu<:«-d 
transfor,  where  the  eonpicte  tile  resiites  uu  a central  ised 
repotjitory  until  i convenient  tie!  i very  time.  This  method  u^es 
not  require  both  source  and  destination  to  be  up  at  the  same 
tune,  and  is  simiiai'  to  the  MAIL  facilities  on  Tenex.  There 
messaqes  were  tjueued,  ami  delivered  when  hosts  cone  t:at;x  on 
the  network.  The  classic  AiIl’ANLi'  pattern  ot  networi-;  iisac;e 
'.i.e.  file  transfer  with,  on-line  users'i  re.i  ies  on  bicii,  oandwidth 
ciiiinneis  witi'  comptirati  vclv  low  ut  i lisation;  t.hi  uueuc.i  tiiti  lu-'acii 
;s  used  mainly  with  scarce  ro.sourcf’s,  such  as  ILLIAC  ’ , 
arcf’.ivi'd  files  and  MAIL.  lurtnei  Len-'fits  of  tht  ''ciit  ral  i sod 
approach  is  the  ability  to  keep  r(A'eri.!s  of  aii  tii-nslcrs  for  a 
specific  period,  allow  retries  etc.  bi  s.-clvantaqos  of  the  approach 
include  tne  need  for  high  amounts  of  t.-icking  si  ..re,  the  need 
to  f.eep  journals  of  transact  ion:; , c.:id  the  inability  to  correct 
erroneous  commands  (e.u.  niis-spe  1 1 1 r ; of  passwords).  A^l 
approaches  will  need  accounting  and  passwords  to  regulate  nateway 
usage.  At  the  present  time  this  a{proacii  is  unuer  study  as  a 
reseircii  student  sfc.uy  t.cpic  at  UCL,  und  it  is  tne  direct  mapt'od 
solution  which  will  he  used  for  real  traific  Itvuis  in  lh77  at 
UCL.  The  staged  .approach  to  file  tr.insfor  is  similar  to  classic 
Message  Svitcliino;  it  shoulii  be  considerably  cheaper,  because  we 
do  not  need  to  retain  iournais  of  the  whole  files,  but  lust  records 
of  the  history  of  the  files. 

We  will  now  present  a little  more  detail  on  the  first  direct 
mapping  approach  currently  being  iraji Lernented ; a full  description 
und  analysis  of  the  method  must  await  impiementation  exp.orience 
and  use  during  1977.  We  have  defined  an  internal  file  transfer 
description  format  rather  similar  to  the  LPSS  definition.  The 
initiating  file  transfer  request  defines  a control  connection 
at  the  SWL'J'CTl  level  for  tliat  network  only  (in  otiior  words  a 
LWITCii  ALLOCATL  luncl  U'n).  Tlu'  roquost  is  tr.inslatcd  int.o  the 
internal  form  for  the  request,  and  a LWITCII  CONNLCT  call  is  made 
to  establish  .t  connect  ion  to  the  appropi' i .ite  file  transfer  option 
in  the  iiost  software  in  the  riesti  nation  network.  In  practice 
this  is  not  a conventional  SWITCH  ci'nnection.  It  makes  use  of 
SWITCH  addressing  capabilities  to  route  the  request,  to  the  right 
place.  It  also  uses  tne  a.it.i  iiatli  si'-t  up  for  the  data  exchange 
sequence  of  the  file  transfer  (Imt  not  obeying  the  terminal  protocols) 


Or.oe  iraploi..ont i.'U  triocl,  .v’e  should  probably  odd  the  correct 

additional  primitives  separately  from  the  current  ones  used 
for  virtual  tormitiai  mapping.  In  addition  to  the  data  path  set 
up  in  readiness  for  the  data  transfer  phase,  a control  path 
across  .SWI'l'Cli  is  now  established  such  that  the  reply  to  t;:e 
initiatinc;  messagi'  :iuiy  i)c  coiiv'eyt'd,  together  with  suusequent 
cont  rol  o‘Xciian(;es . In  fact  tiu-  liPSS  style  of  control  allows 
fiexibii'  va  r i .ii>  j e- 1 en<j  L ;i  control  messages,  eacii  specifying 
options  recpu.'sten  or  t f onr,iti on  on  tht'  tr.insfer.  There  is 
provision  for  coni  iimai  e.in  or  it'jection  raessages  to  be  returned 
to  i.-acn  ijf  tile  options  I'l.'gues teii , such  that  a mgotiated  conmon 
undr-r  s tana  1 ng  is  acn  i cv^>ci  on  iiow  the  requested  transfer  can  be 
majiped  onto  the  facilities  available  on  eacii  network. 

(Jne  interi'St  ing  atiaitionai  iioint  on  tiiis  interface,  is  that 
it  iias  been  aefiriiHi  in  sucii  a way  tnnt  it  docs  not  have  to  be 
interpi'eted  local  iy.  A r t<.iciimcnt  of  the  CULiiAy.  processor  system 
will  be  aecompi  i siieii  sucii  tnat  ail  relevant  file  transfer  interface 
interpretat  i('n  aiui  tesponsa  will  take  pKice  in  fnoir  front-end 
processor,  i iirou<|ii  a si-pai  iie  control  pita  mu  1 1 ip  Lc.xed  witn 
tiicir  data  patii  on  t l,c  same  piiyi.ical  ^duinncl. 

4.3  UCL  work  in  1 ntci  network  i ni)  Usinej  Strong  i.nd-to-End  Protocols 

The  TCP  protocol,  described  in  Section  b,  was  conceived  as 
meeting  botii  tne  o'ojections  to  earlier  host-host  protocols,  and 
meeting  ’-..a  nee. is  oi  an  i nternet>'ork ing  framework,  wnere  strong 
ond-Lo-er.a  ci  ntrol  .ilLowca  tile  need  t>'  m.ike  r.inimal  assumptions 
about  intermediate  nctworKs.  it  is  no  accident  that  the  blN/ 
CYCLADES  [irotocol  uc-ars  many  s imii n r it  ics ; botli  were  conceived 
to  fill  precisely  tiie  .same  role.  Many  of  tiie  conclusions,  from 
exper  i mentu  L I on  with  TCi’  apply  to  tne  E1\/CVCLADES  work. 

Tf.e  1 ni  ernetworK  1 ng  environment  in  wiiicn  TCP  is  most  appropriate 
IS  Ucser  iDeu  in  most  ui'tail  in  (lieOier , 1 97t>)  . Here  arc  propounaed 
tiie  iiU'as  ol  .1  ' -iuiH'rni.'t  ' oi  g.itcway.s,  ci'ntraiiy  regulated  by  a 
ipitcway  control  ccntri',  a.s  wouLii  be  tne  noues  of  a single  net. 
liach  gateway  oOcys  only  a singile  dat.igram  protocol  to  its 
connecting  network,  init  oocys  a much  more  compie.x  gateway-gateway 
[protocol  to  haiuii('  dynamic  routim;  and  m.a inteniince  functions 
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•ippropr  latc  to  a supornodc.  Th»s  ur;v i ror.; . -m.  i s anather^a  to 
tao  conir.crcial  carriers,  who  would  I : Kc  to  cur.strain  carefully 
the  Internetwork  paths  for  reasons  of  control  of  traffic  revenue, 
ease  of  accountiny  and  national  control  of  tratf:  It  is  an 

environment  which,  may  well  apply,  however,  in  situations  wh.ere 
the  inteqrity  of  the  data  networks  is  of  paramount  iryiortance . 

The  SATNhT  of  Ciiaptei'  7,  is  at.  .n.-oroj  >r  i .■  t c testbed  for  this 
form  of  internetwork  iiuf , and  the  Pill'll  macnine.;  proci  ramir.cd  to  carry 
out  only  the  most  basic  of  ttie  ’ sui-er-nodo ' functions  are  being 
installed  in  tne  four  terrestial  access  points  to  SAThKT  (Section 
7.2).  Apart  from  the  general  implications  of  tnis  approach,  many 
detailed  points  arise  from  the  introduet  iiii  of  Gateways;  as  the 
SATN'tlT  ones  will  not  become  full/  functional  until  the  second 
tjuarter  of  1977,  there  has  been  some  time  t'>  consider  some  of 
the  relevant  problems  i.n  detail.  OiiO  important  ; rcblcmi  will  be 
the  maintenance  of  SATNIIT  through  tiie  gateways;  mother  is  access 
in  transitional  staije;;  where  pa  r t n' u>a  tory  measurement  or  other 
hosts  are  still  obeyimi  AHPA  protoet'ls.  A i.ote  ( H inch  1 ey  , 1 9 76P’ ■ 
deals  v/ith  some  of  these  prolilers.  While  som.e  problems  iiave  a 
general  significance  (the  maintenance  -if  one  network  through 
another,  will  bo  important  in  some  situations)  otiiors  arc  more 
iiarochi.il  issues  of  a transitional  software  natuiu'. 

At  a more  general  level,  we  at  UCL  do  not  think  that  the  idea 
of  a central ly-contro 1 1 (,'d  homogeneous  super-net  of  gateways  is 
acceptable  outside  DoD  circles.  Further  work  is  needed  to  identify 
precisely  what  information  must  be  passed  between  gateways. 

Adoption  of  full  dynamic  routing  would  put  a lai'ge  additional 
load  on  the  conncctin<(  networks  and  would  alsc>  be  resisted  by  the 
Ctirriers.  However,  some  alternate  routing  is  ii.'guircd  in  many 
configurations.  In  the  li<jht  of  wide  acceptance  of  X25  procedure, 
the  apjproach  of  using  end-to-end  protocols  across  datagram  nets 
may  be  of  limited  appl  i cabi  1 i ty , althoufjh  directly  relevant  whore 
participatory  nets  are  closely  'bound'  i.o.  packet  radio  nets 
attached  to  a terrestrial  net.  The  need  to  consider  different 
ajiproachcs  was  propounded  by  (L  loyd , 1 9 7h  ) . From  his  work  and 
that  of  ( Kir stein , 1 9 76B ) , we  have  proposed  the  concept  of  transit 
and  terminal  gateways  in  the  i nter net work imi  framework.  This 
ide.i  iias  led  to  some  of  the  ext'cm  imet; ' a we  plan  for  1977/78, 


winch  arc  aiscusscd  furtiier  in  Section  4.4. 


From  experiments  with  the  TCF,  discussed  i.n  Chapter  5,  vje 
conclude  that  it  is  difficult  to  achieve  both  end-to-end  flow 
control  and  hiqh  tliroucjhput . We  believe  tJiat  there  are  many 
important  unresoLvod  issues  in  tne  trade-offs  on  end-to-end  flow 
control,  Cateway-Cateway  conirois,  hiqli  tiirouqhput  gateways 
and  protocol  interference. 

4.4.  UCb  Approaelies  to  InternetworK  ing  i’lanned  for  1977,78 

From  ttie  prt'coding  sectiorts  it  may  b<.'  seen  that  we  at  UCL 
clearly  feel  th..it  tne  previous  models  for  internetworking  are 
of  limited  appl icaui 1 i ty . Overall  guiding  factors  must  be  the 
types  of  services  reijuired,  and  tiie  topology  and  behaviour  of 
network  interconnection  wnicii  wouid  nicet  these  demands. 
Particularly  attention  must  be  paid  to  PTT  developments  in 
standards  and  pianning. 

Solutions  must  resolve  issues  of  address  i ni; , routing,  sequencin 
flow  control,  eongestum  control,  retransmssion/secure  delivery, 
f ragmentation.'reassembl y , access  control,  status  information  and 
iiccount  imj . It  would  be  presumptious  to  suiipose  that  UCL 
activities  in  1977/78  can  liope  to  resolve  all  these  problems, 
but  wo  have  a rcasoniible  framework  in  wliicli  to  validate  sub-areas 
of  tiie  complete'  model.  So  far  we  have  contended  that  end-to-end 
cal  l/association  is  the  desirable  goal,  not  totally  conution  higher- 
xevel  protocols;  we  also  think  that  substantial  inter-gateway 
protocols  and  algorithms  will  oe  roquireu,  but  not  of  the  types 
yet  proposed.  We>  assume  that  this  framework  produces  a 'strongly- 
connected'  'super-net'  character  isc'd  by  transit  gateways  acting 
as  store  and  forward  nodes,  aiui  subject  to  necessary  congestion 
control  only.  At  the  pcripht'ry  of  the  ' strongly-connected ' set, 
will  be  terminal  </ateways  talkimj  to  the  source  and  destination 
of  traffic.  These  may  be  hosts  themselves,  a single  network 
path,  or  even  multiple  nets.  The  latter  we  define  as  'weakly- 
connected'  nets;  aithoufjh  they  may  have  gateways,  they  do  not 
obey  specific  inter-gateway  protocols.  Performance,  and  throughpu 
on  connections  to  these  'weakly-connected'  nets  may  be  lower  than 
in  the  'strongly-connected'  case.  This  may  still  be  the  optimum 
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conC  qurat  ion  when  the  traffir:  loaci  docs  not  justify  full 
interconncccion  wncn  t.Uo  attachment  is  a limited  t ruiis  i t iona  1 
stage . 

In  the  overall  framework  we  must  allow  constructive  co-operation 
between  necessary  use  in  some  cases  of  the  ond-to-ond  protocols, 
and  the  use  of  X25  typo  interfaces.  T<i  achieve  tnis  co-operation 
the  gateway  will  neea  to  [irovide  ,i  TCP-iieo  protocol  in  order 
botii  to  provide  a secure  path  acro;;s  tae  'strongly-connected' 
part  of  tlio  internet  i.'onnection,  and  ii  I so  ti'  provide  an  inter- 
gateway flow  i:ontr<il  mechanism  between  terminal  aitcways. 

•ve  presup[x>se  tti.it  dvn.iinic  rout  i ruj  will  not  tic  justifiable, 
iind  alternate  rout  i ng  st  r.itegic.s  rmi\  !>.'  noL'deti.  In  tiie  case  of 
mapfied  virtual  call  ciateways  for  examT:le,  this  will  reijuirc 
common  alcjorithnis  at  I’UP  1 1 (j.itew  when  an  miward  call  is 

ornken,  attempts  must  be  made  to  la.-estatil  ish  it  by  an  alternative 
route,  and  provide  necessary  forward  ami  b.icKward  siunilling  to 
clear  the  broken  sections  of  th  rra.tc,  and  return  to  an  orderly 
establ  isliment . Moreover,  acce.ss  control  status  repoiting  and 
accounting  will  be  .a  necessary  part  of  tiie  i ntor-cateway  protocol. 

We  will  clearly  iiave  a fertile  tost  bed  of  rr.any  networks  and 
gateways.  Figure  4.2  shows  c partial  configuration  of  those  that 
will  bo  accessible  from  UCL  by  the  niiddle  of  1977.  While  none 
of  these  networks  support  X25  interfaces  at  tliis  time,  we  hav’o 
other  .ictivities  planiuid  for  1977  to  implement  tiiis  .icccss 
protocol.  We  v/ill  certainly  examine  it  expor  imonta  1 ly  at  UCL 
for  network  interconnection,  and  hope  to  be  in  a position  to 
experiment  outside  UCL  at  an  early  date. 

in  view  of  the  current  interest  in  X25,  mention  of  some  of 
our  planned  ac  tivitie.s  Is  appropriate.  An  internal  note  ( K i r stein  , 
1976C)  has  explored  the  nuifiping  of  terminal  and  call  protocols 
such  that  X25  interfaces  may  bo  constructed  and  mapped  onto 
existing  network  facilities.  An  alternative  approach  is  to 
exiieriment  solely  with  existing  pirotocols,  but  in  such  a way  that 
the  results  may  be  applied  to  X2'i  nets;  the  topics  quoted  earlier 
in  tins  section  on  call  mapjiing  setup,  disconnection,  and  flow 
control  arc  <)ood  examples  - especially  when  their  significance 
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is  (.‘xpL  cHSi.a  in  i.rins  ■>:  several  i r.  t ereonnt  -ted  : i-cworkt; 

racher  than  ;asl  a biiatoral  connection.  Gt ner  X25  related 
topics  include: 

1.  Choice  of  teimi.nal  protocols  in  X2'l  inter- 
connected nets 

2.  Protocol  choii'es  on  connection  of  private 
nets  intr  X25  nets 

1.  In  111  cases,  the  application  of  any  hinher- 
Uvc-i  protocol  with. in  ti'.cse  eiv’ironments  is 
d.-erv  Miq  of  : * udy . quite  apart  from  wider 
IMP  1 i c it  ion.s  '1  i nternet  work  i na  . 

One  xe/  question  wh  ic;i  we  have  not  re.solved  is  whether  to  attor.pt 
to  impienient  .uiy  .ippropriate  hiqher  level  protocols  on  ARP/iNET 
hosts.  Wo  could  impienient  them  only  or.  L'K  hosts,  and  use  .aRP.AXET 
just  as  a tc.^t-lit'd.  Such  an  activity  would,  however,  be  very 
artificial  compared  to  real  implementation  and  operational 
experience.  This  is  one  of  the  questions  which  will  be  addressed 
in  tile  ARPA  i nternet w._  rl.  Plan  which  is  beinq  formulated  at  the 
tune  of  writinq  this  reiiort  . 
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CHAPTER  5: 


HE  TRANSMISSION  CONTROL  PROGRAM 


5.1  Introduction 

In  (Kirstein , 1976A)  , we  described  our  work  on  one  of  the 
possible  procedures  for  end-to-end  conmunication  through 
concatenated  networks.  In  this  procedure,  special  software 
is  put  into  each  host,  and  a special  Internet  Packet  (IP)  is 
defined  to  allow  a universal  host-host  protocol  to  be  adopted 
across  the  different  networks.  At  the  gateway  a minimum 
function  is  required  in  this  approach;  however  the  host-host 
protocol  must  be  comprehensive . Cerf  and  Kahn  (Cerf,1974) 
defined  a possible  protocol  which  has  been  much  extended 
(Cerf, 1976).  Its  embodiment  is  here  called  the  Transmission 
Control  Program  (TCP) . 

The  TCP  has  been  implemented  by  three  groups  at  BBN  (Tomlinson) , 
Stanford  U (Cerf) , and  UCL.  A final  report  of  the  findings  of 
the  experiments  is  in  preparation  (Cerf, 1977).  The  UCL  interest 
in  the  TCP  has  several  origins.  We  are  interested  in  evaluating 
the  suitability  of  the  protocol  for  different  internetwork  operatin 
environments;  we  v/isii  to  be  able  to  propose  simplifications  and 
improvements.  Finally,  the  PDPll  SATNET  Gateways  of  Fig.  2.2 
use  the  Internet  Packet  Header;  therefore  we  have  a practical 
need  to  have  an  efficient  implementation  of  the  TCP  to  pass 
traffic  over  SATNET. 

In  Section  5.2  we  will  discuss  the  experimental  tools.  These 
include  methods  for  Time  Stamping  packets  at  critical  points, 
ability  to  change  parameters  remotely,  and  a careful  design  of 
the  experimental  controller  and  traffic  generator. 

In  some  ways,  the  experiments  raised  more  questions  than  they 
resolved.  For  this  reason,  we  also  resorted  to  other  experiments 
and  simulation  methods.  In  one  different  set  of  experiments,  we 
examined  the  behaviour  of  an  individual  packet  passing  between  the 
IMPS.  In  this  way  we  were  able  to  disentangle  end-to-end 
behaviour  from  delays  encountered  inside  the  Data  Transmission 
Network. 
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In  SocLion  5.J  3om<2  actL.^1  exp&ri r.f.-rital  results  are  presented. 

We  nave  mentioned  that  the  experimeni-s  denci  Lbed  are 
difficult  no  o;;!-ry  out.  For  this  re'son  we  have  also  embarked 
on  a simulation  exercise.  The  simulation  is  particularly 
useful  in  o'cluiting  proposals  to  improve  the  protocol.  3om.e  of 
cur  activities  in  this  field  arc-  described  in  Section  5.4.  Finally,  I 

conclusions  are  present ea  in  Section  5.5.  ' 

5.2  Expo iii'it .Its  and  Tools 

5.2.  1 Ai([!s  anil  :',:vlronr:icnt 

A gieat  deal  can  j'c  learnt  a'eout  the  TCF  threugn  theoretical 
iiiscussion  of  protucoi  feature-  and  by  stepping  the  implementations 
tiirough  the  packet  transmission  ;..i-.icess . However,  many 
questions  regarding  practic... j.  ^ mp I i.  mentcitions  cannot  be  answered 
this  .v’ay.  What  throughput  can  we  actually  achieve?  If  it  is 
« poor,  why?  Whui:  retransmission  ti.meout  should  be  chosen? 

What  are  the  effects  of  dxffi,ier.t  lufferinq  strategies?  In  order 
to  answer  questions  such  as  tiiose,  a quantitative  progranme  was 
developi-u  and  a n alor  of  experimento  wcic  carried  out  between 
the  various  groups. 

The  einp'iiasis  ox  the  experiments  was  on  learning  the  effectiveness 
and  coc.sti-,';  L ets  of  TCP  performance.  Thus  we  were  principally 
interested  in  x i.uLning  the  throughput  achieved  and  the  delays 
experienced  ly  p.ickets  under  various  constraints.  Very  early  in 
the  proqramcit  was  decided  to  separate  the  TCP  from  the  rest 
, of  the  universe;  thus  data  was  to  be  collected  as  seen  by  the 

TCP  process,  and  the  experimental  parameters  varied  were  to  be 
i ones  which  were  specifically  features  of  the  TCP  protocol.  The 

parameters  used  ari-: 

I i)  Winaow  size:  This  is  the  basic  flow  control  of 

the  [irotocol  . Window  size  is  defined  as  being  the 
I amount  of  information  the  TCP  is  prepared  to  have 

t outstanding  at  any  mcnent.  Measurements  were 

carried  out  on  constant  windows  fixed  by  the 
axper  imonttir . 
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ii)  Maxinuira  packet  size:  This  parameter  is  determined 

more  by  tne  properties  of  the  traffic  and  the 
transmission  characteristics  of  the  traffic 
medium  than  by  an  internal  TCP  constraint.  At 
UCL  it  was  fixed  to  be  the  size  of  the  maximum 
ARPANET  packet  of  bytes  (whicn  allowed  90  bytes 

of  TCP  data) . 

iii)  Thrash  size:  Tf  viata  is  ueinq  acknowledged  at  a very 

slow  rate,  tJie  avail  ibie  window  at  tne  sender  site 
may  be  very  sman,  loading  to  pacxets  being  fragmented 
into  many  small  segments.  Tnrasn  size  is  the  parameter 
which  defines  the  minimuni  size  fragment  the  TCP  will 
generate  for  tr  insmission  purposes.  In  the  experiments 
undertaken,  it  was  felt  desirable  to  avoid  fragmentation 
altogether-  tiius  thrash  size  was  set  to  the  size  of  the 
packets  beirig  sent. 

iv)  Retransuiission  timeout;  Tliis  is  ti;e  length  of  time 
whicn  passes  before  an  unacknow iciiqed  packet  is 
retransmitted.  Ideally  it  should  be  set  to  just  above 
the  round  trip  time  for  the  majority  of  packets.  In 
practice,  in  experiments  wiicre  one  could  assume 
arrival  was  guaranteeu,  an  'infinite'  retransmission 
timeout  was  set  to  be  8 seconds. 

A number  of  parameters  are  implementation  dependent,  or  data 
dependent.  These  included  items  such  as  choice  of  buffering  str 
egy  whicfi  arc?  not  easily  uutintif  i ^loic  or  variable,  but  which 

may  have  to  be  taxen  into  consideration  wnon  understanding 
final  results.  The  items  considered  were: 

i)  Packet  size;  As  tlie  TCP  window  is  clearly  related  to 
the  amount  of  information  outstanding  it  is  important 
to  study  tne  effects  On  performance  of  tne  amount  of 
data  being  transferred  in  any  given  packet.  The 
limitations  are  those  imposed  by  the  need  for  a full 
timestamp  field  (i8  bytes)  at  one  end,  and  the  maximum 
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ARPA  packet  size  (90  bytes)  at  tiie  other  at  UCL. 

ii)  Choice  of  acknowledgement  strategy:  It  is  possible 

either  to  force  out  separate  acknowledgements  (ACKs) 
for  each  TCP  packet,  or  to  piggyback  ACKs  on  existing 
traffic  in  the  other  direction  where  possible.  The 
choice  of  strategy  may  enhance  or  degrade  performance, 
depending  on  the  nature  of  the  traffic  flow;  an  ACK 
is  needed  to  stimulate  furtiier  transmissions,  but 
may  take  up  considerable  bandwidth  in  a congested 
channel.  UCL  chose  a strategy,  whereby  one  checked 
that  there  was  no  packetised  information  pending 
anywhere,  before  forcing  out  an  ACK.  However,  one 
may  still  compare  the  two  strategies  by  setting  up 
appropriate  traffic  situations. 

iii)  TCP  buffering  strategy;  As  noted  above,  the  protocol 
places  qrecit  importance  on  the  relationship  between 
window  size  and  buffer  constraints.  As  the  measurements 
opted  for  a fixed  window  size,  they  also  opted  for  a 
fixed  buffer  strategy. 

The  buffer  strategy  chosen,  which  proved  flexible  enough 
for  most  reejuirements , was  to  maintain  a large  fixed  buffer  pool 
from  which  fixed  sized  blocks  could  be  chosen  as  needed.  Space 
was  grabbed  according  to  demand  for  transmission,  and  for 
reception  was  chosen  so  as  to  maintain  at  least  one  outstanding 
receive  buffer.  If  serious  space  limitation  problems  occurred, 
the  experiment  was  abandoned;  this  tended  to  occur  in  the  UCL 
experiments  with  larger  window  sizes  as  there  was  no  necessary 
connection  between  the  arbitrary  window  size  chosen  and  the  amount 
of  space  available.  Prolilems  caused  by  choice  of  buffeiing  strategy 
were  extensively  studied  by  BBN,  and  led  to  a re-examination  of 
many  areas  of  the  protocol,  which  were  considered  by  the  simulation 
study  of  Section  5.4. 

Finally,  in  order  to  observe  the  interaction  between  TCP  and 
tiie  ARPA  subnet,  one  could  vary  the  ARPA  packet  type.  This  is 
a ready-made  control  for  examining  the  effects  of  subnet  flow 
control  on  TCP  performance  and  vice  versa.  Type  0 ARPA 
packets  are  subject  to  the  full  ARIA  end-to-end  flow  control; 
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type  3 to  none.  However,  type  3 packets  run  the  risk  of 
being  discarded  at  any  point  on  route  if  blockages  are 
experienced. 

5.2.2  Configurations  and  Methods 

Throe  basic  traffic  situations  were  identified  which 
it  was  felt  could  give  infomiation  on  different  aspects  of 
TCP  performance.  These  wore:  the  seif- loop,  the  source- 

sink  and  the  echo-loop.  In  the  self  loop,  transmitted  packets 
were  received  on  the  same  TCP  port.  In  the  source-sink 
case,  traffic  was  received  on  a different  port  which  did 
not  reply  beyond  acknowledging  it.  Finally,  the  echo- loop 
echoed  received  traffic  to  the  sender. 

The  self- loop  v/as''ucod  to  give  an  indication  of  the 
optimum  TCP  performance 'in  various  situations.  The  TCP  is 
doing  a minimal  amount  of  work  in  that  it  is  transmitting  and 
rec-iiving  on  the  s.ime  TCP;  ail  acknowledgements  are  automatical! 
piggybacked,  and  no  extensive  manipulations  are  required. 

This  i'lop  is  not  possil^le,  however,  if  the  TCP  is  talking  to 
a TCP  in  a remote  machine.  The  source-sink  and  the  echo- loop 
provided  more  normal  situations,  reflecting  full  and  half 
duplex  connections.  The  source-sink  case  by  itaelf,  however, 
could  not  give  information  on  end-to-end  delays  to  a remote 
TCP,  and  this  could  only  be  obtained  by  using  an  echo  connection 
In  order  to  obtain  data  usable  at  UCL,  echo  connections  were 
almost  always  used  for  experiments  to  remote  sites. 

Behaviout  was  studied  in  several  different  physical 
configurations,  illustrated  in  Fig  5.1.  Two  local  loops  were 
used.  In  the  "internal  loop",  TCP  packets  were  placed  on 
a transmission  queue,  and  when  they  reached  the  head  of  it 
were  immediately  transferred  to  the  receive  queue.  In  the 
"IMP  loop",  packets  were  transmitted  to  the  London  IFP 
across  a iocai  host  interface.  A similar  "VDH-IMP  loop" 
was  tested  but  was  abandoned  due  to  hardware  problems  and 
an  unsolved  lock-up  condition  in  the  VDH  RTP.  Traffic  was 
also  sent  to  a remote  site,  usually  Stanford,  although  some 
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self connection  source-link  echo  loop 

a)  Internal  loops 


F i y 5.1 


The  Experimental  TCP  Configurations 
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connections  were  also  made  with  BBN . 

In  order  to  examine  the  effects  of  UCL's  relative  isolation 
from  the  main  ARPANET,  two  configurations  were  studied.  In  one, 
traffic  was  sent  across  the  standard  .NORSAK  route,  a channel  whose 
nominal  capacity  is  9.6K  bps,  but  with  an  effective  data  capacity 
of  between  5.1  and  7.6K  bps  for  ARPA  host-to-host  packets  depending 
on  whether  seismic  data  is  being  transmitted  from  NORSAR.  Tills 
channel  is  cledirly  a bottle-neck.,  and  one  can  expect  delays  to  build 
up  in  Norway  and  at  SDAC  on  tiie  return  journey.  The  other 
configuration  was  to  use  the  50K  bps  channel  provided  for  the 
broadcast  satellite  experiments  using  Pl’DMi  to  five  a one-way 
capacity  of  25K  bps.  In  this  case  the  potential  bottleneck  is  the 
9.6K  bps  London-Goonhilly  link. 

To  obtain  figures  on  throughput  and  delay,  one  has  to  know 
the  times  at  which  various  events  occur,  the  critical  interfaces 
being  the  point  at  which  a packet  enters  and  leaves  the  TCP. 

Thus,  the  basic  tool  for  measuring  TCP  behaviour  was  a Timestam.p 
packet,  which  picked  up  timestamp  values  at  these  points.  As 
packets  might  bo  sent  to  either  a sink  process  or  an  echo  process, 
the  following  events  had  to  be  allowed  for: 

1 . Generation  at  source  process 

2.  Transmission  from  source  TCP 

3.  Reception  at  destination  TCP 

4.  Reception  at  destination  sink/checker 

5.  Departure  from  destination  echoer 

6.  Transmission  from  destination  TCP 

7.  Reception  at  source  TCP 

8.  Reception  at  source  logging  process 
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By  including  aii  offset,  field  to  point  to  the  first  unstamped 
location  in  the  f'eld,  the  timestamping  procedure  was  made 
simple  to  code  and  operate.  The  format  is  illustrated  in 
Fig  5.2. 
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Fig  5.2  Timestamp  Packet  Format 


Throughput  can  be  calculated  from  the  differences  between 
corresponding  timestamps  in  successive  packets,  delays  from  the 
difference  between  timestamps  in  the  same  packet.  Throughput 
was  measured  directly  in  terms  of  the  number  of  letters  trans- 
mitted per  second  by  the  source  process,  where  a "letter"  in 
TCP  terms  is  simply  a unit  of  data  which  has  logical  significance 


I 

to  t;ic  usi‘r  proccsrioii.  It  w.is  ijaickly  lounii  t;;.it  i r.  order  to  ‘ 

■enderstand  what  w^is  iiappeniruj  in  the  TCP  in  tr'iits  Lf^tw«_'rri  UCl. 

and  remote  sites,  one  would  need  riiore  dot.ii;  th<in  rould  no 

providoG  oy  the  overall  status  times  obt^ilned  from  timestar.n 

data.  To  obtain  this  detail,  two  levels  of  packet  tracing 

were  used.  Une,  adoptee  at  botii  CCL  and  Stanford,  v/as  to  dump  ^ 

each  TCP  packet  on  transmission  and  rcci'pt  i on . This  was  usee 

principally  in  tieiiugi;  ine  niu;  in  vaiiou.s  robustness  eenior.  str  at  ic.-.s  , 

nucii  as  demons L r a 1 1 mj  tne  correct  beiiavtour  of  various  protoccl 

lentures.  A iiori’  sopli  i s 1 1 ca  i ee  vc'i'sion  of  tin'  ;;  imi.'  trace  was 

imp  i ementeil  at  HB.\  . 

In  addition,  packi'ts  passing  throucii  tne  I.^.-ndon  IV.P  could  be 
trii.’od  using  tne  teciiniguo.s  described  in  Section  8 . f>  this 
report.  owing  to  tiie  resourci-s  needed  and  ..i  riinbor  of  hardware 
problems,  this  [jroccdurc  was  only  used  er.cr  successfully.  It 
proved  extremely  useful,  iiowi'vcr,  in  pointinc  out  important 
^ind  unsuspecteci  TCP  interactions. 

'j.2.j  experimental  Softwari’  ' 

i 

In  ordiT  to  support  tlu''  f.iciiities  descrini'd  alievipCCL 
lievi'lopeti  nil  iiitegrntod  .set  of  software  maintain  the  followinc 
TCP  [in  >(■< -sses  : 

i)  Manual  oxei'ciser:  'i'tiis  opened;  and  eloscv;  connections 
ana  proven'd  basic  messai^e  transmission  f <.ic  i 1 1 1 los  . It 
was  intendeil  primarily  to  aomonstrate  tne  correct 
lunctioning  of  aspects  of  tiio  'i'CP  prcitoci.  1 . 

ii)  iiciioor:  A pa.ssive  process  was  mai  nt  i .ned  w-iiicii  always 

had  open  a listening  I'cho  socket,  am;  which  cciioed  any  j 

aat.;  sent  to  it.  It  was  intondmi  to  be  used*  with,  the  j 

1 

.'■(•mote  parameter  idiamie  i^iciiity  .;iid;  ,is  suen  was  j 

rengers'd  invisibli’  both  t..)  tlu'  Ik’I,  I'xper  inion'ter  a.na  t.ie  i 

li.it.i  loiiging'  softwaie.  As  the  reriof  e i>arameter  ciiangt  ! 

w.is  only  iniplemt'nLe'd  at  UCl,,  Lhi.s  niwAW'd  to  be  an  unwi.se 
(K'ci.sion  in  experiments  with.  .Stanford. 

Ill)  Tr.ufiv-  C.em'rator:  Tn  1 r,  maintained;  a .-onst.intly  slocked 

'i'Cl'  t I'.insii.  1 ss  ion  interface.  'I’raffie  of  a fixed  letter 
sixe  wais  iJiacica  on  tile  transmission  ^jueue  whenever  tiic 
'i'Ci>  informed  the  process  tnat  tiio  packet  queue  was  bocominc  ir.w. 
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This  meo'hanisni  ensured  that  traffic  qeneration  would 
occur  at  the  optimum  rate,  which  could  thus  be 
measured  directly. 

iv)  Parameter  Change:  This  was  a special  process  which 

could  request  or  implement  parameter  changes  for  both 
the  local  and  remote  sockets  of  a connection,  and  thus 
in  theory  enabled  a TCP  experiment  to  be  run  by  one 

side  only.  In  practice  it  was  only  ever  implemented  at  UCL, 
due  to  space  restrictions  at  Stanford. 

v)  Data  Logging:  All  incoming  data  was  routed  through  this 

process  which  selected  timestamped  packets  at  regular 
intervals,  and  monitored  parameter  change  responses  as 
well  as  maintaining  a watch  over  background  inform.ation 
such  as  the  opening  and  closing  of  a connection. 

All  these  processes  could  be  driven  either  from  a command  console 
or  automatically  from  commands  stored  in  a command  file,  written 
in  a simple  control  language. 

Post-processing  facilities  remained  rudimentary.  It  was 
originally  intended  that  the  TCP  data  captured  should  be  logged 
onto  magnetic  tape  for  subsequent  analysis;  but  owing  to  numerous 
teething  problems  with  both  TCP  and  the  tape  hardware  and  software, 
this  was  never  implemented,  and  proposals  for  a certain  amount 
of  run-time  data  reduction  were  not  studied  until  late  in  the 
project.  Both  timestamp  data  and  the  TCP  packet  traces  were 
logged  onto  the  line  printer,  with  the  user  specifying  the 
interval  at  which  timestamp  packets  were  traced.  Subsequent 
reduction  was  carried  out  by  hand. 

These  limitations  were  never  a serious  problem,  as  the  experi- 
mental program  never  reached  the  stage  of  generating  a volume  of 
data  too  large  to  handle.  All  throughput  and  delay  measurements 
were  made  by  sampling  every  tenth  incoming  packet  from  a group 
of  lOO;  the  sampling  indicating  the  uniformity  of  the  sample. 

Thus  a very  few  calculations  actually  had  to  be  performed  for 
each  point. 

5.3  Experimental  Results 

For  a fuller  treatment  of  the  experiments  conducted  and  the 
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results  obtained,  the  reader  is  referred  to  the  TCP  report 
(Cerf,1977).  This  section  outlines  the  results  obtained  and 
discusses  their  significance  for  the  TCP  in  the  UCL 
envi ronment . 

5.3.1  The  UCL  Implementation 

A large  number  of  experiments  were  carried  out  in  the  two 
UCL  configurations  of  Fig  5.1  - internal  loop  and  IMP  loop. 

As  a result  of  the  early  measurements  undertaken  a number  of 
serious  inefficiencies  were  revealed,  which  were  corrected, 
although  the  UCL  TCP  is  still  inefficient.  For  instance, 
under  our  PDP9  operating  system  the  new  occurrence  of  an 
event  (eg.  I/O  interrupts)  is  indicated  by  a known  global 
flag  changing  state.  The  scheduler  at  some  later  stage 
detects  the  change  and  passes  control  to  the  appropriate 
service  segment.  This  scheduling  by  flag  causes  delays; 
for  example,  even  though  there  are  packets  awaiting  trans- 
mission, the  data  will  not  go  until  the  transmit  state  flag 
is  inspected  in  the  scheduling  loop.  It  was  found  that  in  a 
heavy  traffic  situation  the  hardware  data  adaptor  was  idling  for 
relatively  long  periods.  Although  a simple  rewriting  of  the 
TCP  scheduler  resulted  in  a dramatic  improvement  (see  Fig  5.3), 
the  adaptor  was  still  underutilised.  The  round  trip  figures 
of  Fig  5.4  for  the  UCL  IMP  represents  an  effective  capacity 
of  26.35K  bps  across  the  local  host  interface,  which  has  a 
nominal  rating  of  lOOK  bps.  This  suggests  that  even  in  the 
comparatively  idle  situation  represented  here,  the  UCL  TCP  is 
compute -bound . Results  in  later  experiments  support  this 
conclusion . 
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Window  size:  96  bytes 
Packet  size:  18  bytes 

Thrash  size:  18  bytes 
Retransmission:  8 seconds 

Conf iyuration:  self  loop  to  IMP 
Solid  line:  old  scheduler 
Broken  line:  new  scheduler 

Fiy  5.3  Transmission  Queue  Delays  in  the  UCL  TCP 
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Cor.  f njuracton  :<o. 

UCI.  intornai 
u’Cl.  IMP 

St.i.'i ford  V 1 .1  \OI\SA.< 
ataniorii  vi.i  C.ooai.iliy 

I'.ickot  s i ze  = 18  Ljytes , 'i'i'.rasii 
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vvindow  sizes  = 18  bytes  (to  St: 
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Fi(j_  ^.4  'I'ypieai  Round  'I'rip  Tines  for  a ita  rt  i cul  :-i  r uxperir.ent 

'I'lU'  results  of  a tytucaL  tiir..)uqhput  .-'xperinent  are  siiox:'.  i r. 
;'i(i  '..O.  liere,  tit'  increast'  of  t n rouqnput  .v  i t li  one  ciannc  ct  ier. 
vs  with  two  (.-oi.iu-cr  i ons  is  I . 8u  (lor  the  ii.ternal  loop)  itn; 

(ioi  till-  IMP  loop).  'I’i-.e  remarkabte  aqreement  of  tiit'se 
two  fiqures  aqairi  sutiuorts  .i  sinijiie  process-bound  model  of  tnc 
bCl.  TCP.  In  this  model  the’  throughput  per  connection  for  a 
number  of  connections  eacii  handllnq  a similar  load  is  inversely 
proportional  to  tlic  number  of  connections.  Such,  a model  would 
predict  tne  tiirou.jiiput  ratio  to  be  2:1.  tt..'  dii''ference  would 

DC  aue  to  the  minim.um  load  of  idle  processir.vi  not  beiny  taken 
...rito  account. 

Tiirouy.hput  expi'r  iments  involvinci  v.o'iation  of  letter  size,  i;. 
cr.oice  of  ACK  strata’ciy  .liso  suqye.st  inat,  in  situations  w’here  the 
..Cij  'I’CP  w.is  beiny  list'd  for  commun  i cat  i ons  in  .i  hiyh  capacity 
network,  its  use  would  incur  cons  itierai)'.e  processi.ni:  overheads. 
Aitnouyh  ottier  yroups  had  the  same  I’xperience,  tiiis  does  not 
.iieari  thal,  iiii'  'IVP  is  nc't’cssa r i ly  wasteful  of  proc. 'S.i ina  cycles. 
I'he  proble.m  is  laryely  due  to  inefficient  desi.jn;  t'ne  basic  reas 
tor  tliis  will  Ijc  discussed  later.  .\'cw  TCPs  currently  beiny  im- 
plcmenteo  oy  otlicr  (jroups  appear  to  ue  much  more  efficient  tnan 
tniii  earlier  i-mpiementations , and  uoubiiess'.y  we  wouidi  see  the 
.-,ame  th  I ny  with  trie  UCb  TCi’  if  it  were  rewritten  suitably. 


a)  iMiternal  loop 


Letter  size:  18  bytes 

Retransmission:  8 seconds 
Solid  line:  echo  loop 


Thrashsize:  18  bytes 
Broken  line:  self  connection 


b)  IMP  loop 


Fig  5.5 


Throughput  for  one  and  two  connections 
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) , , 2 I r*  to  x*no  t Wi ' !'.<  I'.y, [jc  r i ,.jO»i  c w i zi\  ' i ' 

A numoor  oi  experi.iionts  were  porfonr.od  m oonjuncti.on  .v.Lh 
tno  TCP  qroui-.  >ii-  Stanford  Univers.-ty  wnicn  provijod  in  :','rr.atiori 
on  t;ie  TCP's  ability  to  function  in  a more  qenoralised  not/.-or-: 
environment  than  was  obtain. lule  in  the  Locai  i Cl,  test  ,s  'nen 
i’lcj  5.1).  It  snouid  he  pointed  viut  tnat  ti.e  practie.i,.  d i f f i - 
culties  encountL'rcd  were  eonsid,cinib]e , w . tii  ; le  resu.t  tn.o 
■r,  aiy  experiments  ciri  *.j  i na  1 Ly  planned  v.ei'.'  ".ever  eo-.iduetrs.  - .ni 
extreme  exporii'nee  invo^veii  coord  . nat . n>.;  ‘;;.e  .let  i \’i  t ,-es  er 
four  dispersed  qrc.'ups  (UChA,  NCC  < l.ondon  ani.;  .it.rvnfor...  ■ .iver  a 
period  of  tnrci.'  (iays,  only  to  nave  tht'P  .iarie.y  w.isrea  ;ue  to  a 
C0.T.01  na  L ion  of  runninq  i nco.mpatiuic  versions  >'f  i ne  TCP, 
encountorinq  an  unsusp(?ctcd  variation  in  tl'o  r.ax  imum  s i ,:e  of  an 
ARPA  packet-  '"lohinc  failure  cau.sed  by  e tropical  hurricane,  and 
failure  in  UCbA  and  London  nonitorinq  software. 

in  these  exfie  j- 1 me  nts  , traffic  wa.s  sen!  to  Stanford  under  three 
sets  of  conditieiic.  'i'ype  / trail  le  wa.-'  sent  acress  tne  XORS.AR 
link,  and  typi'  d .mti  type  .1  t ,i  1 iC  w.is  sent  .loros.s  CiOtinn  i 1 i y . 
r’(5r  alt  runs,  mi  ti  c muc.  jMex^ii.r-  (iB  d^it  ; liyiea)  were  simI;  tv',  an 
ecliocr  at  Stanford.  I'ixi’er in,en  1 s usi  ne  type  1 packet  s acress 
XOKSAH  and  usinq  larqer  p.ie.-'.ets  were  planned  but  were  never 
.successfully  he  lei.  Ttu'  \t)RSAK  run  shown  iiere  was  accompanied 
by  the  low-level  packet  tivice  discussed  in  Section  8.G.  I rom 
the  d.iUi  'tnus  obt.i  ir.t'd  we  'woro  .idle  to  extract  finures  on  the 
numiier  of  ret  ransmi  ss  i c<ns  at  line  level  for  most  points,  and 
i.so  sor.ie  .lactet  nistories  wi,ich  proved  particularly  i 1 lumd  nat  i n -i . 

'■iinimuiii  load  round  trip>  times  .ire  shown  in  Fiq  5.4.  .A  simple 
mode , I con t- r ue  t v''tl  purelv'  o.n  t ni  basis  ot  known  channel  Cvipacitiv'S 
(ie'.is  ovc'rlie.ids  f r<  im  lUMtlern, , ro'ut  i nq  pacxids,  KPXMs  etc)  , 
incite. ites  that  tiiooo  oc' 1 ays  I'ont. un  no  features  of  any  s i qni  lican.'O 
.It  .in  1 nte  rii' ■ 1 w.  irk  1 nq  levr'l,  t tie  main  eon  s L rco,n  L ' k' i nc]  simply 
the  capacity  of  Liu'  (.'lianin'ls  en  route.  Tiie  tin  , 'uqirpu  t curves 
(sitown  in  l■■iq  5 . (> ) over  Cooniiilly  support  Uk'  picture'.  Ti.e 
maxiimim  t,i roucihpul.  to  Stanforvi,  G.85  letters  per  second,  I'opreser. t .c 
i i.no-lcvei  th  rouvil'.put  of  4.1iK  bps  for  letters  of  this  si.-’e. 

The  sa.iie  tr.roucfni.nit  for  full  lenqt!".  pciCkeSs  wc.uLd  represent  a lir.- 
level  rate  of  7.9K  bps,  whicn  would  represent  a nea r-,max i.m.u'' 

Mt  1 1 i.s.it  i on  of  tiu^  9.GK  b|is  channel  from  London  to  Goonhiii'/. 

'i'yfie  1 [xieKots  arc'  thus  limited  only  by  t!ie  narrowness  of  t;ic 
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Fig  5.6  Tliroughput  to  Stanford 
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•••.'...nnc' I . 'i'he  o f i'ci;  t:  of  nova  ntj  t-wo  oT  r.ont -t.i'-l'.or-t  protocol 

otort  ap[x-arinc;  w;ion  wo  conmaoa"  t;n,-  or.  figures  for  typo 

^ over  cjootiii  1 1 ] y . Ui  s regard  Lr.<_;  rf.o  rata..'’'  .inonialou.s  peak 
obsorvea  at  a window  size  of  ivT  letters,  tne  naximuni  of  4.25 
letters  per  second  corresponds  to  a line  level  rate  of  3.2GK  bps 
and  a predicted  maximum  of  5 . 7K  bps,  ratiaer  below  the  maximum  channel 
rate.  This  would  appear  to  bo  auc  to  the  maximum  limit  of  8 IMP 
buffers  for  a connection  imposed  by  the  t\RPh  as  throughput  starts 
to  level  off  at  this  point. 

The  full  implications  of  cr.c  effects  of  hav'.-ng  two  iiost-to- 
nost  protocols  in  operation  (a  normal  internetworking  environment 
bec.'ime  clear  wiien  we  consiciered.  the  information  gained  from  the 
iinc- Level  measurement  of  Section  8 . (>  obtained  with  tlic  NORSAR 
linn.  The  picture  here  is  more  comp>lox.  'i'he  maximum  throughput 
of  1.75  letters  per  second  ( 1 . 34K  bps  at  line'  lev’el)  occurs  at 
a window  of  4 letters;  this  is  followed  by  severe  degradation 
accompanied  by  a high  level  of  IMP  retransmissions  from  London 
to  NORSAR.  The  effective  capacity  of  the  NORRIiR-SDAC  link  is 
reduced  considerably  by  the  introduction  of  seismic  data  at 
•NORSAR.  A sufficiently  larcje  window  in  the  source  TCP  will 
accordingly  load  to  the  formation  of  a cpicue  at  MORSAR  of  more  than 
8 packets  - the  maximum  allowed.  This  will  cause  an  I.^'P-lcv’cl 
retransmission  after  2 second.s  and  a conseciuent  degradation  of 
inroughpiit.  l.MP-lcvol  ret  ran  .smi  ss  ion  rati's  of  up  tc.i  32.'’.'?.  were 
oiiscrved.  These  figure's  confirm  somc'thing  tnat  Kuropean  users  of 
flic  ARPAMIT  h..velomj  suspected.  The  ARPANL'i'  l.MP-iMP  protocols, 
wh  1 cii  are  perfectly  satisfactory  on  the  h iqii-capaci  ty  iow-delay 
50K  iips  lines  for  which  they  wen  ucsigned,  are  not  really  adequate 
for  the  Low-cafiac ity  hiqh-delay  satellite  link  wr.ich  connects  us  to 
the  US  side.  The  figures  show  more  than  this,  however.  TCP 
throughput  is  reduced  further  by  the  fact  that  the  TCP  duplicates 
features  of  tiic  AHPA  net  protocols  - in  particular,  retransmission 
and  positive  acknowledgement.  Since  the  IMP  cannot  distinguish  a 
'I’CP  retransmission  as  sucli,  we  end  up  in  tdie  situation  wh.ere  tiie 
London  1 .MP  is  stiil  ret,  ransm  i 1 1 i ,i  TCi'  ret  ransmi  ss  ion  of  a packet 
that,  ti'ie  UCb  'i'CP  a 1 really  knows  has  arriveti  si.i'cess  f ul  ly . T’vus  i r. 
till;,  sort  of  bad  situation,  the  features  built  in  to  aive  end-t 
i.'nd  security  li'.ui  to  a duplication  of  IMP-lcve;  effort,  increasi'- 
performiince  degradation  as  tr.e  duplication  of  packets  will  only  be 
detected  liy  the'  receiving  TCP. 


5.4 


Simulation  Studies 


As  a result  of  studies  undertaken  at  BBN  (Cerf,l977)  into 
buffer  strategy,  a number  of  proposals  were  made  regarding  the 
relationship  of  TCP  window  size  and  buffering  strategy.  These 
were  investigated  at  UCL  by  a simulation  study  of  methods  of 
credit  return.  In  TCP  credit  is  returned  relative  to  the  last 
acknowledged  packet  and  defines  a contiguous  area  (the  window) , 
extending  in  the  data  stream  from  the  end  of  the  data  in  the 
last  packet  acknowledged,  in  and  only  in  which  the  sender  is 
allowed  to  transmit/retransmit  data. 

Generally,  as  packets  are  acknowledged  by  a TCP  on  behalf  of 
a receiving  process,  credit  is  also  returned  dependent  on  the 
amount  of  unfilled  storage  in  the  Receive  Buffer  Queue  and  in 
TCP  storage  allocated  for  the  Receive  Packet  Queue.  Two  general 
approaches  may  be  distinguished.  In  conservative  schemes,  the 
allocated  credit  must  be  guaranteed  by  available  storage  which 
may  come  from  internal  TCP  buffer  exclusively  allocated  to  the 
process,  and  from  any  user  buffers  which  are  provided.  In  the 
variant  proposed  by  BBN  there  are  no  buffers  provided  by  the 
TCP  and  the  window  size  is  governed  purely  by  the  buffers  made 
available  for  the  connection  with  the  received  data  being  placed 
directly  in  tic-  user  buffers.  In  optimistic  schemes,  of  which 
the  fixed  control  window  used  in  the  experiments  discussed  in 
Section  5.3  is  an  example,  sometimes  more  credit  may  be  granted 
than  is  actually  available,  on  the  assumption  that  the  extra 
storage  will  become  available  later.  It  is  clear  that,  provided 
no  subnet  loss  occurs,  a conservative  scheme  is  100%  efficient, 
since  space  is  always  guaranteed  on  the  receive  end.  However, 

■with  optimistic  schemes,  it  is  possible  that  packets  may  have  to 
be  discarded  as  the  promised  space  may  not,  in  fact,  be  available 
when  they  arrive. 

In  considering  these  schemes,  we  should  bear  in  mind  the  general 
criteria  by  which  they  may  be  judged.  These  fail  into  two  groups- 
resource  protection  (achieving  maximum  efficiency,  minimum 
storage  utilisation,  minimum  CPU  utilisation  by  the  TCP)  and 
service  utilisation  (maximising  throughput,  minimising  delay). 
Throughput  will  be  governed  by  the  minimum  of  the  channel  band- 
width, the  sender  production  rate  and  the  receive  consumption  rate. 


■Si'.ould  depend 


A further  ODjCctive  may  ho  taut  the  per forr.ui'ioe 
as  little  as  possible  on  tno  prceessos  eonnoeto*d,  tr.oaeh  tnis 
has  been  deliberately  rejoctea  in  3BX  schor.ic . The  criteria 
are  somewhat  incompatiole ; it  is  unlikely  that  any  one  protocol 
will  succeed  in  optimising  ail  flow  control  objectives  simultan- 
eously. Tne  simulation  is  also  affected  by  a number  of  external 
events  of  the  kind  we  have  noted  in  previous  sections:  traffic 

distrioution  patterns,  process  iiroduction  and  consumption  rates, 
local  host  activity  and  subnet  behaviour. 

Three  particular  schemes  were  simulated  udige,l076)  - the 
iioN  vers  ion  of  a conservative  scheme,  the  general  conservative 
scheme,  and  the  general  optimistic  scheme.  T!ic  conservative  BBd 
scheme  was  also  studied  analytically  on  a simplified  model  with 
an  exponentially  varying  subnet  delay  neld  constant  for  all 
packets  in  the  same  receive  buffer,  and  re  - ’ '-e  buffers  for  the 
optimistic  scheme,  and  the  results  of  this  were  compared  with  the 
sim.ulation  results. 

'I'wo  variants  were  simulated.  One  - used  in  every  simulation 
study  - reguirc's  all  arriving  oui-of-oniei  p.ickets  to  be  stored 
temriorarily  in  the  Receive  Pack(^t  Queue  - if  tnerc  is  room.  The 
other  is  based  upon  the  BBN  scheme  of  using  constant  length  Receiv 
Buffers,  made  known  to  the  sender.  This  allows  out-of-sequence 
entry  of  data  to  Receive  Buffers  when  the  correct  Receive  Buffer 
for  a particular  piece  of  data  is  present. 

Tiic  results  ootaincd  with  tlie  various  cr-edit  return  schemes 
are  discussoc;  m detail  in  ( Kdgo , 1 0 70 ) . Typical  results  are 
shown  with  figures  in  Fig  1.7.  We  will  summarise  the  ros-uits  here 

In  cji'neral  , throughput  with  the  BBR  .iciieme  is  very  sensitive 
to  particular  process  behaviour.  It  will  Improve  considerably 
if  one  has  a lanje  number  of  small  buffers  ratiier  than  a small 
numl)er  of  largo  buffers.  However,  throughput  and  delay  vary  in 
a Similar  way  to  buffer  utilisation  and  are  shown  to  be  hiahly 
dependent  on  it.  Consccpucntly  this  sci-.omc  is  very  sensitive  to 
icttcr/buf far  size  mismatch.  General  sensitivity  of  tne  BBX 
■senomo  ii;  loss  in  an  environment  of  low  subnet  delay,  tho'ugh  as 
wi tn  all  schemes,  throughput  anc  efficiency  arc  reduced  if  the 
saunct  is  unreliable.  Ideally,  a large  number  of  small  Receive 
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ijuffers  snouiti  no  used  - given  a corcain  amount  of  Receive 
dU''for  storaqc  avui;.ablo,  it  snouic  be  split  into  many  small 
buffers  rather  than  a few  large  ones.  Tne  letter  size  should 
sc  matched  to  the  buffer  size.  When  subnet  propagation  delay 
IS  low,  these  factors  are  less  crucial. 

I'or  the  general  conservative  scheme,  iiiqh  ti'.rouqhput  is 
obtained  at  the  cost  of  setting  aside  largt'  CiUantities  of  TCP 
storage.  Sensitivity  to  process  iieiiaviour  is  also  apparent, 
but  loss  so  than  in  the  BB\  scheme.  Rougiily  equal  amounts  of 
botal  storage  (from  the  TCP  6,  Process)  are  needed  in  tliese  and 
the  BBN  sc'neme  to  achieve  the  same  througiiput.  When  both  schemes 
are  idealised  (with  respect  to  process  beiiaviour)  , storage 
(Receive  Buffers  in  BBN  and  Receive  Packet  queue  storage  in  the 
General  Conservative  scheme)  spends  most  of  tiie  time  'in  the 
TCP'  performing  the  functions  of  a Receive  Packet  Queue. 

With  tile  OiiLimistic  Si-heme,  liit;)'  th rfiaghput  is  obtainable  at  a 
cost  to  the*  effi  ciency,  ind  to  tiu'  amount  of  ICP  storage  sot  aside 
or  averaije  TCP  storage  utilised  from  a commiin  pool.  Much  Less 
storage  overall  is  needed  to  tibt.iin  a given  tiirougiiput  tiian  in 
i'ithor  of  tlie  oLIht  sclienn's. 

Fiijurc  5,8  briefly  summarises  the  extt'nf  to  wliien  the  various 
schemes  s.itisfy  the  flow  control  criteria  listeii  above. 
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It  is  seen  that  no  single  scheme  manages  to  achieve  all  flow 
control  objectives.  Some  are  achievable  only  at  the  expense  of 
others  or  through  special  process  behaviour.  In  practice,  choice 
of  a particular  scheme,  for  a communications  system,  will  depend 
on  the  priority  attached  to  each  objective.  This  in  turn  will 
depend  on  the  availability  of  resources  within  TCP  using  hosts, 
the  kinds  of  communication  envisaged,  and  whether  or  not  processes 
served  by  TCP's  can  be  expected  to  participate  in  achieving 
flow  control  objectives. 

The  use  of  a particular  scheme  by  a receiver  TCP  is  completely 
transparent  to  the  send  TCP  with  respect  to  protocol  functions 
and  interferes  very  little  with  protocol  functio.is  at  the  receiver. 
Thus  communication  between  machines  using  different  schemes  is 
not  disbarred,  and  each  TCP  in  a network  may  use  one,  several, 
or  all  the  above  schemes,  depending  on  resource  limitations  and 
its  requirements. 

5.5  Conclusion: 

The  lessons  that  can  be  drawn  from  the  UCL  experience  with  the 
TCP  fall  into  two  broad  categories:  those  that  related  to  our 

specific  implementation,  and  those  of  more  general  interest. 

Many  of  the  implementation  lessons  we  learnt  were  not  drawn  directly 
from  our  experiments  but  from  the  background  work  in  setting  them 
up.  The  UCL  TCP,  in  common  with  most  of  the  other  early  TCPs, 
was  large  and  complex;  typically  the  size  of  the  TCP  was  of  the 
order  8-10  K.  It  took  over  6 months  to  implement,  and  was 
accompanied  by  long  and  painful  debugging  sessions.  In  these 
circumstances  it  is  not  surprising  that  our  local  measurements  show 
low  throughput  and  high  processor  time.  The  only  first  generation 
TCP  that  did  not  show  these  defects  was  the  TCPO , a single- 
connection TCP  implemented  on  an  LSI  1 1 at  SRI,  which  was 
rendered  much  simpler  by  discarding  the  multiplexing  function. 
Obviously,  this  is  not  in  general  an  acceptable  choice,  but  it 
does  raise  the  question  of  what  protocol  simplifications  can 
reasonably  be  made,  which  we  shall  return  to  later.  Later  versions 
of  TCPO  have  included  the  multiplexing  function  with  relatively 
little  increase  in  program  size. 


— TIJ  — 


Undoubtedly,  part  of  the  reason  for  TCP  inef ficiency  is 
connected  witn  various  operating  syster  features  wnicr.  have 
aign  ovcrnead  costs..  In  the  3SN  TCP,  '.■’CNKX  JSVS  traps  were 
identified  as  a major  source  of  overhead.  In  the  UCt  TCP  intersec~e 
caiis  and  the  run- to-complct  ion  nature  of  tiie  operatinq  system  were 
identified  as  sOi ices  of  waste.  However,  a much  more  fundamental 
re.ison  for  the  problem  is  simply  lack  of  experience  of  implement- 
ing protocols  of  this  order  of  complexity.  For  instance,  we 
saw  that  rewriting  a mere  50  lines  of  code  - the  TCP  scheduler  - 
resulted  in  a lO-fold  improvement  in  tiu>  transmission  queue  delavs. 
Otni'r  TCl’s  now  being  writti'n  seem  to  be  much  smaller  and  >"ere 
^■liicient  than  the  early  ones,  basoi.!  on  the  di'sien  lesson  learnt 
from  the  first  implementations.  One  problem  is  that  the  TCP  is 
really  only  completely  specifiable  in  a suitable  I'.igh  level  lar.au.iae 
altnough  we  did  have  an  incomplete  BCPI,  li  stint]  of  Stanford's 
TCP,  the  original  specification  was  written  in  English  and  we 
did  not  attempt  to^write  our  own  in  a suitable  hiuh-lev'el  form. 

There  is  a clear  need  for  such  a specification  for  future  im- 
;> -cmontat  ions . 

Given  tiiuc  the  implementation  left  mucii  t,t'  'oo  desired,  the 
t;uestion  still  remains  as  to-  wliat  changes,  if  any,  siiould  be 
maut'  to  tlie  protocol,  and  how  will  they  impact  tiio  efficiency  of  the 
iiiipiomentation . 'I’lic'  BRN  proposals  studn''d  in  tiur  simulation  work 
were  clearly  intended  to  make  tiu'  implenumt  at  i an  less  complex. 

From  the  point  of  view  of  protocol  dosicn,  th.c  chanqes  proposed  arc 
fairly  small  - the  soquence-nuiniicri  ruj  scheme  is  i'artially  de- 
coupled into  separ.itc  control  and  data  sequences,  and  tiic  window 
becomes  specifically  a description  of  the  available  buffering 
at  rno  receivers  end.  From  the  implementation  point  of  view, 
tne  cnanges  are  dramatic;  they  moan  that  packets  can  be  placed 
directly  into  the  correct  position  in  user  buffers,  thus  avoidino 
tile  whole  process  of  letter  reassembly.  Moreover,  this  means 
tnat  the  'I’t’P  no  lon<;cr  needs  to  manage  its  own  internal  storaoe 
for  "cush  1 f)n  i ng " a user  process  currently  unable  to  accept  receivovl 
data.  'I'he  effect  on  the  TCP  is  a redact  ion  in  its  i ntc  1 1 igcnce , 
as  :L  is  reduced  from  being  an  active  participant  in  makinu  flow 
control  <lcc:  i s i ons  to  being  a carrier  of  dc'cisions  made  effectively 
oy  the  r<'i:eiving  process. 
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As  the  simulation  studies  noted,  this  reduction  in  intelligence 
makes  the  throughput/delay  characteristics  much  more  sensitive  to 
tiie  behaviour  of  inaividuai  processes.  In  particular,  efficient 
throughput  requires  that  send-letter  size  be  matched  closely  to 
rece i ve-buf fer  size,  and  the  end-of-letter  flag  thus  becom.es  an 
indication  to  the  sending  process  that  it  should  pad  out  the 
rest  of  the  current  transmission  buffer.  In  other  words,  the 
concept  of  "letter"  takes  on  the  specific  meaning  to  the  TCP  of 
"receive  buffer  size".  Since  the  earlier  function  of  "end-of- 
letter"  as  initiating  reassen±)ly  automatically  disappeared  in 
the  BBN  scheme  the  idea  would  appear  to  have  no  me  ining  to  tlie 
protocol  in  the  proposed  revision.  To  a user  process,  a letter 
was  intended  to  be  a unit  of  data  with  logical  significance. 

Not  all  user  processes  will  have  need  for  such  structuring,  and 
thoses  that  do,  will  contain  indications  of  it  in  the  data  field 
in  any  case,  so  the  user-orientated  definition  of  a letter  would 
also  appear  to  be  redundant.  At  least  under  the  BBN  scheme, 
therefore,  there  is  a strong  argument  for  eliminating  the  "lett.er" 
altogether. 

If  the  simulation  studies  suggest  that  tne  BBN  proposals 
potentially  simplify  the  relation  between  the  TCP  and  the  user 
processes,  the  crossnet  experiments  indicate  the  failure  of  the 
TCP  to  relate  to  existing  ARPANKT  protocol  structures.  This  would 
appear  to  bo  a general  problem  for  internetworking  - the  potential 
for  redundant  activity  between  protocol  layers  has  already  been 
pointed  out  for  the  X25  protocol  agreed  for  PTT  network  access 
iPouzin  1976).  We  certainly  intend  to  study  the  implications  of 
this  situation  as  part  of  our  internetworking  activity  in  1977. 

The  importance  of  these  interactions  depends  very  much  on 
the  future  direction  of  internetworking.  If  all  internetwork 
conm\un icat ion  is  to  be  handled  by  a network  of  gateways  acting  as 
a transit  net,  then  we  have  a very  clean  design  environment  in 
•which  the  problem  disappears.  On  the  other  hand,  the  situation 
fjf  concatenated  networks  across  which  we  must  maintain  an  end-to- 
end  connection  of  an  indefinite  number  of  network  hops  presents 
serious  difficulties  of  this  kind  for  any  end-to-end  protocol. 

What  appears  to  be  needed  is  a defined  "network  interface"  which 
would  enable  the  protocol  to  decide  when  certain  functions  should 
be  suspended.  This  was  done  on  an  ad-hoc  basis  to  the  ARPANET 
protocols  governing  the  establishment  of  a virtual  connection,  since 
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obviou^^ly  viuo . . c>i t fs  tno  fv^nv'-  ion  in  tho  TCP.  The 

nor.nnl  proceauro  of  dofininq  a link  nuiiiber  of  link  0 was  suspendinq 
m favour  of  usinq  a "wcli-known"  link  nuniner  aqreed  in  advance. 
However,  it  is  clearly  not  possiole,  in  tjcneral  , to  suspend  a 
function  by  user  aiktat  and  a more  formal  procedure  should  be 
found . 

In  short,  tho  conciusio.ns  we  have  drawn  from  our  experience 
w 1 1 ;i  the  TCP  sucjqest  that  not  only  would  it  benefit  from  more 
careful  desiqn,  but  also  from  design  decisions  and  protocol 
ciiancjes  whicn  make  it  less  ratiier  than  more  intelligent.  As 
an  I'nd-to-end  protocol  , the  'I'CP  shoulo  act  as  a carrier  for  flow 
control  decisions  ratner  than  as  a particip..nt  in  tnem.  As  an 
internetworking  protocol , it  needs  to  find  a method  of  dividing 
responsibility  for  protocoi  functions  between  itself  and  the 
various  network  protocols  it  encounters  in  transit.  By  following 
these  leads,  wo  should  be  able  to  produce  a TCP  which  is  better 
designed,  smaller,  more  efficient  and  less  complex  than  tho  exist- 
ing one. 
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UCL  ACTIVITIES  WITH  EPSS 


0.1  Introduction 

In  Section  4.5  (Kirstein,  1976A),  we  mentioned  our  plans  to 
connect  one  PDP9  to  the  UK  PO  Experimental  Packet  Switched  Service 
(EPSS).  The  UCL  configuration  has  been  shown  in  Fig  2.1.  Our 
progress  has  been  slower  than  anticipated,  mainly  because  EPSS  has 
had  some  unexpected  delays. 

•At  the  beginning  of  1976  EPSS  was  providing  an  echo  service  for 
hardware  testing  by  which  all  packets  sent  were  subsequently  returned. 

The  service  was  gradually  advanced  to  provide  calls  to  oneself,  calls 
to  test  number  and  calls  to  other  users  on  the  same  Packet  Switching 
Unit  (PSU) . This  last  state  lasted  a considerable  time  and  was  made 
more  difficult  by  the  availability  of  only  three  48K  bps  ports  on 
the  London  PSU,  to  be  shared  between  the  five  users  roijuiring  access, 
of  wtiich  we  and  the  Rutherford  Laboratory  are  two.  Service  was  (and 
still  is)  Monday  to  Friday  mornings  only  (8.45  to  13.00),  and  this 
rf.'stricts  .iccess  to  what  is  normally  regarded  as  prime  time.  A 
r-.jirked  ii,\provement  in  the  level  of  service  came  in  the  late  Sumjiier 
when  trunk  switching,  a second  London  PSU  and  access  from  character 
terminals  became  available.  With  minor  improvements  tliis  is  the 
current  situation.  A PSU  became  available  in  Manchester  and  in 
Glasgow  during  the  course  of  1976. 

v*e  have  had  to  modify  our  communication  hardware  to  cope  with 
LESS;  The  modifications  arc  discussed  in  Section  6.2.  We  decided 
to  develop  the  Lower  level  software  in  a structured  way.  Our  progress 
iiere  is  discussed  in  Section  6.3.  It  was  felt  very  important  to 
yet  early  real  experience  with  EPSS;  therefore  both  the  Rutherford 
Laboratory  and  ourselves  decided  to  mount  an  experiment.  In  this 
we  It  UCL  sinyily  adapted  the  software  module  driving  the  communication 
tievice  on  the  leased  line  to  be  able  to  make  a call  through  EPSS.  RL 
iiae  to  make  many  more  modifications,  since  they  drive  EPSS  via  a front-end 
comtputer.  This  activity  is  discussed  in  Section  6.4.  We  still  plan  to 
supriort  services  better  via  EPSS;  our  immediate  jilans  are  discussed 
in  Section  6.5. 

6.2  UCL  Hardware  and  Lino  Handlers 


In  order  to  connect  to  EPSS  we  purchased  a Transmission  Protocol 


w'na.t  (VPu)  . V..XS  ur.xt  vjat,  aci-igned  by  ^ group  of  users  and  the  ?0; 
its  devc iopnicnu  cost  was  supportea  by  me  PO  and  it  was  iraiiuf actured 
oy  Computer  blectronics  Ltd.  The  TPU  ciiecks  incoming  packets  for 
line  seiiuence  number  and  CKC ; it  passes  all  packets  received  to  the 
processor  anu  appends  a status  byte  to  tnc  end.  On  transmission  the 
processor  passes  a packet  to  tiio  TPU,  wiiicn  adds  a line  sequence 
nuraber  and  CKC  before  sendiiK;  Lt  on;  the  TPU  keeps  a cop>y  of 
the  pficr'.et  so  tnat  any  retransi.iissions  necessary  can  be  generated 
internally.  The  TPU  has  a V24  modem  interface  to  the  processor,  so 
that  standard  interface  boards  can  be  used  on  tiie  processor.  The 
usual  control  signals  of  the  V24  interface  are  used  to  control  the 
TPU  and  to  signal  status  from  the  TPU  to  the  processor.  Tl;e  TPU 
performs  the  iine  initial isation  and  loop  delay  measurement  proced- 
ures required  by  UPSS  without  processor  interventions. 

Tlie  standard  I’DI’U  synchronous  adaptor,  wliich  is  used  for  all  ot'r.e 
reiuote  links  except  the  CUC,  iiad  to  be  modified  in  order  to  cope 
witn  tne  higlier  speed  of  Lne  bPSS  line.  The  adaptor  had  to  be  modif 
ied  to  switcii  automat  ical  ly  from  its  "Ignore  SY.\"  state  to  its  "Pata 
Channel  Keceivf'"  state  so  that  c'naracters  would  not  be  lost  if  an 
interrupt  for  another  device  were  being  serviced.  The  software 
handier  for  this  adaptor  iias  been  written  to  support  both  the  TPU 
and  the  "Simplified  Protocol"  of  SPSS.  This  second  protocol  is  aval 
able  as  an  alternacive  to  using  a TPU;  however,  it  has  a much  higher 
processing  ovcriicad  and  it  is  not  clear  that  it  ca.n  be  adequately 
supported  by  a PDP9  at  48K  bps.  The  code  was  written  as  a "backup" 
in  case  tnc  TPU  was  late  or  unreliable,  but  neither  of  these  even- 
tualities occurred.  The  simplified  code  will  be  used  to  test  out 
ttie  secfind  2.4K  bps  line  (see  Section  (>.5)  when  it  arrives. 

G.3  Software  for  SPSS  Attachment 

Ttic  line  handler,  the  adaptor  and  the  TPU  were  tested  using  a 
packet  ijencrat-or  in  the  PDP9  and  the  loop  facility  either  in  the 
PSU  or  interna i to  the  TPU.  Several  points  of  ambiguity  with  regard 
to  'I’i'U  operation  were  uncovered,  particularly  witn  regard  to  the 
status  sicinais  .md  SYN  sd-iucnces.  Uhese  came  to  light  only  when 
the  TPU  w.'is  connected  to  a processor  thre-ugh  a standard  modem  inter- 
I'ao’c  .ind  the.se  [joints  were  passed  o.n  to  other  TPU  users. 
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Much  planning  and  some  codinq  of  the  call-level  software 
had  teen  done  during  1975;  however  greater  clarity  from  later 
dociimentation  and  a better  understanding  of  the  SV-JITCH  interface 
necessitated  some  revision.  In  addition  it  was  realised  that 
the  number  of  protocols  that  had  to  be  supported,  and  the  desire 
to  be  able  to  add  monitoring  tools  and  possibly  datagram  access, 
required  that  a more  rigid  and  well-defined  interface  between 
programmed  processes  and  the  EPSS  call-control  software  be 
defined . 

Implementing  this  new  interface  involved  reorganisation  of  the 
call-control  software.  The  delay  that  this  caused  was  well 
justified  by  the  ease  with  which  the  standard  RL  360  driver  from 
the  RL/ARPANET  system  was  interfaced  to  EPSS. 

This  unconventional  use  of  EPSS  is  discussed  in  the  next 
section.  The  standard  interface  is  also  being  used  for  the 
File  Transfer  and  Virtual  Call  Protocols,  which  are  planned  for 
implementation,  and  for  the  Virtual  Packet  Terminal  Protocol 
li.e.  the  protocol  for  character  terminals  dialling  up  the  PSE) , 
which  v/as  coded  and  being  debugged  at  the  end  of  the  year.  All 
the  EPSS  software  runs  under  SWITCH,  and  could  be  run  in  a multi- 
machine, multi-network  environment. 

6.4  The  Packet  Hasp  Experiment 

The  Packet  Hasp  Protocol  was  developed  jointly  by  the  Rutherford 
and  Daresbury  Laboratories  as  the  simplest  modification  that 
could  be  made  to  connect  a standard  multileaving  workstation  to 
the  Hasp  program  on  the  360  over  EPSS  or  using  EPSS  protocols  over 
leased  line.  The  workstation  uses  a single  EPSS  call  onto  which 
all  the  data  for  the  card  readers,  line  printers  and  interactive 
terminals  is  multiplexed  in  the  standard  way.  So  far,  use  of  this 
protocol  between  UCL  and  RL  has  proved  its  viability  and  usefulness. 
During  the  first  quarter  of  1977  we  will  also  monitor  the  performance 
of  EPSS;  the  Packet  Hasp  system  is  particularly  suitable  for  this 
because  it  keeps  up  a one  second  exchange  of  messages  even  in 
the  absence  of  user  traffic. 

Tiio  Packet  Hasp  system  became  operational  during  the  fourth 
qiiarter  of  1976.  We  now  run  test  sessions  for  an  hour  or  so  per 
day,  in  which  UCL  staff  do  routine  work  via  the  UCL  TIP  and  the 
1TJP9/ARPANET/EPSS  gateway.  At  present  the  system  requires  a 


(leclicdt ud  i’:  ! ' ; bcivh  for  t r.  i s r.-oroTi  ii.d  h.'cause  of  ■ it^  d 

vivailabil  it  y of  h I’SS , wc  do  iioi  pi  ^tn  to  oi  ror  a scrvioo  oat.Sioc' 
Ll’.C'  IH'I.  q'^  up  t>--fv're  the  second  qi.  liter  oi  M77. 

Packet  Mvc.p  rcMji'.i  I'c's  a i;  i ipi  i ! i cant  ly  ureater  number  cf 
packets  to  be  [)assi  d over  KPp.S  than  is  needed  for  tiiat  amount 
of  useful  <lata  I i' inr.mi  r.s  ion  . Tiiis  extra  tr.'.ffic  during  idle 
periods  is  us-Mui  .it  l!ie  monent . However,  tariffs  have  been 
.innounced  for  a'PSS,  which  ar.;  t'cheduled  to  conimence  early  in 
19  78.  These  1 nc  I Ude  .1  v‘iy  a i v,n  i f i c.int  charge  based  on  traffic 
volume  (t0.9h/kiU>  p.^ra'.  Onee  che.rginq  is  introduced,  some 
way  wi  11  h.ive  to  bo  ‘aanui  to  ri.'iiiovc  unnecessary  packets.  This 
would  involve  ut.e  of  .a  i we  or  .l.rtie  buf  ft;r  c.i,  ’ nstcad  of  the 
present  siiajle  but  for  call,  and  {.o-ssabiy  will  require  extra 
hufferinc;  at  ‘-a-n  ei.d . I'he  ower  th  u.  riiiximum  throuqhpuL  is 
not  such  a serious  pivoiei.,  kt  w. ''x.slat  ions  interfaced  at  2.-1 
or  4 . 8K  bps  bci  ause  Lue  tvL  jfiO  i.nterfacos  at  43K  bps.  It  is 
more  marked  > 'H  < 'ir  e-> -m.' -cl  i on , but  wc  would  expect  traffic  to 
other  hosts  t.o  u:u  up  tlie  line  capacity  and  would  not  place 
qroat  empha.sis  on  ; nc  re.a.i  i nq  our  Packt.  t Hasp  throughput.  (A 
throughput  increase  m.jy  come  as  a by-product  of  a two  baffer 
call)  . 


Another  ,asper-t  of  bihS;',  -iiarqing  is  that  some  level  of  empty 
buffer  return  must  .liways  accompany  a one -d  i rect  iona  I traffic 
flow*.  In  fact  this  is  a tride-off  istwecn  user  buffer  space 
and  network  cfiarges  lor  buffer  manatjement  traffic.  The  one 
buffer  case  and  its  potential  massive  ovi'rhead  has  been 
mentioned  already.  A two  buffer  call  can  result  in  a 100% 
overhead  and  a three  buffer  call  in  a 50 i overhead  because  of 
buffer  management  triffic.  two  way  data  flow  of  course  reduces 

the  overhead.  'J'hcre  .ispects  will  bei  examined  during  the  coming 
year . 

0.5  Future  Support  of  Asynchronous  Terminals  and  File  Transfer 

It  is  [jl.tnned  to  support  the  VPT  protocol  (PO,1976)  which  is 
a simple  termin.il  protocol  for  both  incoming  and  outgoing  calls. 
.Since  this  is  .i  "re.il  tr'rminal"  protocol  it  requires  extra 

.ui.ipt  ,it  i on  to  .ind  from  the  SWITCH  viitual  terminal.  The  future 
problems  which  w.,'  are  likely  to  encounter  wicii  this  protocol  aic 
th.it  we  will  h.ive  to  [irovide  different  ad.ipt.at  ions  for  different 

•SiiK'i  this  w.Ts  WLitten  the  P.O  has  _announc'-*d  that  nc  charge  v.ill 
be  mad('  for  buffer  manauement.  traffic. 
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terminals  and  that  we  may  have  problems  with  mapping  other 
hosts  adaptations  back  to  a virtual  terminal. 

However  we  anticipate  no  problems  in  making  initial  connections 
between  EPSS  character  terminals  and  M?1'ANLT  hosts , and  ARPANET  ’ 

terminals  and  EPSS  hosts.  We  also  intend  to  support  any  j 

virtual  terminal  protocols  which  gain  wide  acceptance  within  ' 

EPSS  or  which  seem  to  have  merit  from  an  experimental  poin  of  \ 

view.  The  EURONET  virtual  terminal  protocols  (Higginson, 1976D)  i 

1 

fall  into  this  latter  category. 

The  SWITCH-FTP  primitive^  of  Section  3.3  are  a subset  of  the 
standard  EPSS  FTP  primitives;  hence  we  anticipate  no  theoretical 
problems  in  building  an  interfacing  module  between  the  standard 
process  interface  of  the  call-control  softv;are  and  the  SWITCH- 
FTP.  Planning  of  this  module  is  currently  taking  place  and  we 
expect  it  to  be  operational  during  the  second  quarter  of  1977. 

For  several  reasons  we  have  ordered  a second  line,  at  2.4K  bps, 
to  EPSS.  This  second  line  will  allow  us  to  test  our  gateway 
software  completely.  It  will  allow  also  experimentation  with 
the  software  needed  through  concatenated  networks,  which  was 
discussed  in  Chapter  4.  We  will  experiment  also  with  our 
facsimile  terminal  attached  directly  to  EPSS  via  this  second 
line  (see  Chapter  10). 

When  the  high  level  protocols  have  been  implemented  on  several 
other  UK  hosts,  and  we  have  mapped  the  terminal  and  FTP  protocols 
via  SWITCH  on  to  TELNET  and  the  ARPANET  FTP,  the  number  of  UK 
hosts  accessible  to  ARPANET  will  increase  considerably.  It  is 
quite  possible  at  some  time  that  the  PO  and  we  may  agree  to 
restrict  host  access  to  computers  which  are  attached  to  EPSS,  and 
not  continue  direct  links  like  the  present  Culham,  RSRE  and  ULCC 
ones.  However,  before  this  can  be  contemplated,  the  availability 
of  EPSS  must  increase  very  substantially  - probably  to  at  least 
18  hours/day  from  9am  to  3am.  Even  without  this  liiah  availability 
we  expect  to  have  a considerable  oortion  of  the  UK  traffic 
arrivinn  via  EPSS  durinn  the  second  half  of  1977.  We  cannot  yet 
guage  the  throughput  of  the  UCL  PDP9s  running  the  multi-machine 
system  under  SWITCH,  so  we  cannot  yet  predict  on  which  UCL  machine 
EPSS  gateway  software  will  usually  be  run. 
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'K; oATi:'.;  ; ; kjject 


■■.1  Ob jCJCt.  1 Vt.'s  ._)f  iiLOa0c.»:;t  aatcliitu  Tccnr.j.iues  foi  P.i,'kc-t  5wi- 

Early  work  on  Lroaucast  radio  te.-cniiiquos  in  the  ALO'Oi  orOj^'C”  has 
been  widely  {.luL]  ished , and  io  early  planning  tor  ana  s in'.ula  r lor.  ct 
a broadcast  satelLite  cnanncl  for  packet  switching  {Hinci;icy,  197ib''. 


The  f undaiuenL^bl  oJjjective  is  to  optimise  bandwtdt!:  by  ii.ivinq  all 
stations  transmit,  ^ttid  rect-'ivi-  on  Uir-  same  f t o-ptency . The  degree 
of  sopti  ist  itm  L i on  in  .illov'al  ion  oi  the  ch^inn-  I t-av/.-cn  users  will 
depend  on  t lie  app  1 i c^it  ion . Tin  siiiipli.'st  scheme  .1;  random 

transmissii  r.  intt'  H;e  chaan.  i , witii  ar  r ingeiient i.  a ret  ransmiss  i an 
when  twe  stations  broadcast  a, t tiic  same  inomei'.t;  mere  j mplc.x  schemes 
make  use  ot  tiic  broadcas!  natui  e of  the  men  i .u.,  to  aiicw  all  stations 
to  monitor  closely  the  allocation  of  the-  charmoi,  and  impose  pre- 
reservation  constraints  oi;  v'iitn-iLly  all  use  ui  the  channel 
(Lin-nan  Lee,  l‘J7G;  . 

Tile  broadcast  nature  oi  tne  cliannol  may  be  useci  to  genuinely 
allow  inulti-dcst  uiation  a[)pl  rcat  ions,  sucii  .is  speecii  cenrerenr  a-ng  iv 
He  suipported.  Th'.  iiki i n u.  < of  the  1. 1'l '.ulc.ist  natui'o  of  the  c'lanric^ 
IS  stilL,  liowev'u  , t*j  ^ipt;mi:.e  ci'i.mum  L c.t  L i c US  bandwidth, in  a more 
flexible  way  ti.an  is  posimide  wiin  current  t.echni>  :ui-s . Its  main 
apfdication  is  wiiere  many  s-anrce-des t i n. > t i on  n >ths  may  be  recuired 
concurrently,  and  where  (he  short  term  fluctuation  of  traffic 
density  on  any  one  patn  is  vai  i dile. 


The  packc’  satellite  project  uses  ILTLIjEaT  IV  as  a communications 
medium,  aru’  iuis  used  ARl'ANLT  as  its  constituent  packet  switched 
network.  Neitiior  of  these  is  fundamental  to  tlic  project's  on  jecc  ives . 
In  fvict  , .1  separation  from  AkI’AX'ET  is  scliodtiled  during  1977  into 
a separate  EATNET.  This  de'c.-ision  was  taken  because  of  the 
widely  liirihTirxi  requirements  oi  llie  ffotocois  of  a broadcast 
satellite  cliatinel  eompai'ed  with  tcrrostriaJ  ne'tworks.  This 
fiepaiat  ion  i a i ses  i ntere.U  i ng  questions  on  network  interconnection 
in  will  ell  Ufl.  ex|)ect.s  to  bo  active  rn  I ‘*77  (Se'e  also  dhapter  4)  . 

'liie.;i  i:,.,ui;i  .'.le  i.ot  «i< ili I' I’s si’d  111  doLdll  I’.  t'..is  c..apL»r  ai'-  they 
are  a fu'ture  amivity,  and  Inis  chapter  is  confined  specifically  to 
the  eesiqn  and  measurement  of  SATNET.  INTELSAT  IV  also  is  not 
a necessary  ••ehicJe  for  the  project  - it  v/ould  iiavc  been  possible 
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to  Lise  other  Satellites,  It  is  indeed  possible  tnat  other  satellites 
including  the  European  Orbiting  Test  Satellite,  n y be  used  in  the 
future.  However,  the  present  project  is  concerned  only  with  the 
use  of  INTELSAT  IV,  and  v/ith  ARPANET  as  an  access  network. 

The  detailed  objectives  of  the  project  are  discussed  elsewhere 
(Linkabit  1976) . Because  the  project  involves  many  parties  - ARPA, 

BBN,  COMSAT,  DCA , LINKABIT,  the  UK  Post  Office,  and  UCLA,  it  is 
clearly  not  appropriate  to  discuss  these  here.  For  the  purpose  of 
this  report,  it  is  enough  to  describe  the  actual  configuration  (Section 
7.2)  and  the  general  progress  during  1976  (Section  7.3.). 

The  principal  UCL  activities  in  the  Packet  Satellite  Project  have 
been  to  develop  tools  for  traffic  generation  and  data  acquisition  for 
the  configuration  of  Section  7.2.  We  have  concentrated  on  high  level 
traffic  generation  measurement  outside  SATNET  itself  - though  measure- 
ments data  will  also  be  provided  as  the  traffic  traverses  SATNET. 

While  we  have  been  able  to  develop  the  tools,  in  the  absence  of 
Gateway  computers  and  other  sites,  no  real  UCL  measurements  will  be 
madebefore  April  1977.  The  general  description  of  these  tools  is 
the  main  subject  of  this  chapter,  and  they  are  discussed  in 
Sections  7.4  to  7.6.  Our  progress  during  1976  is  summarised  in 
Section  7.7;  how  the  tools  will  be  utilised  is  tne  subject  of 
Section  7.8. 

Because  the  UCL  measurement  tools  are  directed  at  high  level 
measurements,  they  are  almost  independent  of  the  network  being  measured. 
Clearly  the  packet  formats  and  the  exact  timestamp  mechanisms  are 
governed  by  the  data  network  being  investigated.  Also  the  exact 
parameters  which  must  be  set  are  also  dependent  on  the  data  network 
lacilities.  For  example  there  is  no  point  in  setting  priority, 
rn.  1 1 L-dest i na t ion  or  multipacket  traffic  in  networks  which  cannot 
,*  r f I them.  The  application  of  these  tools  to  SATNET  will  involve 
.mn  by  SATNET  switches  of  additional  information  on  their 
II  ar . For  other  networks,  similar  information  would  have 

. vid*!!  1)/  the  packet  switches  in  the  network  itself. 

. . ; '■  in  i igurat  ion 

• I f J.revity,  it  is  assumed  here  that  the  reader  is 
. n.isii-  ARPANET  technology,  and  the  functioning  of 
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the  Satellite  IMPs  (Butterfield,  1974).  The  present  PSP  conf iguartitr. 
is  ^own  in  Fig.  7.1.  In  this  configuration  the  UCL  Gateway  P^'P  1 1 has 
no  real  function-  t.he  Satellite  IMPs  (SIMPs)  in  the  earth  stations 
[ are  still  connected  to  the  IMPs  or  TIPs  of  ARI’ANBT  in  tiie  norn.ai 

li^lP-lMP  way.  It  is  only  between  each  other  that  they  have  specific 
ways  of  communication  via  the  single  satellite  channel.  The  L’CL 
Gateway  Computer  has  two  addresses  in  the  ARPANET  routing  tables;  it  is 
aost  234,  the  fourth  local  host  on  the  UCE  TIP  (counting  the  terminal 
. luandler  of  the  TIP  as  the  third)  and  host  124,  the  first  Very  Distant 

host  on  the  Goonhilly  SIMP  (which  ARPANET  treats  as  if  it  were  an 
IMP  for  routing  purposes)  . The  path  b€?twcen  Goonhilly  and  ETAM  has 
been  made  to  appear  artificially  long,  so  that  nort.al  US  - London 
ARPANET  traffic  passes  through  Norway  and  not  the  ETAM  - Goonhilly 
path.  This  avoids  the  disturbance  of  mi?atuircm<>nt  experiments  by 
normal  traffic,  but  permits  this  satellite  channel  to  be  used  for 
normal  traffic  if  the  circuits  tlirough  Norway  are  down. 

In  Fig.  7.1.  two  linos  arc  shown  between  UCL  and  the  Goonhilly 
SIMP.  The  53  kbps  one  terminates  on  the  PDPll,  the  9.6  Kbps  one  on 
the  TIP.  The  second  line  has  been  put  in  only  temporarily.  It 
is  to  permit  diagnostics  and  control  of  tiic  Goonhilly  SIMP  to 
continue  via  Norway  from  the  Network  Control  Centre  even  if  there  is 
difficulty  with  the  satellite  channel  within  some  contention  strategy, 

• or  with  some  hardware  modifications. 

The  configuration  will  ch.mcjo  in  several  important  aspects  during 
the  second  quarter  of  1977.  The  new  configuration  is  shown  in  Fig. 
There  will  be  two  additional  SIMPs  - at  the  Nordic  earth  station 
in  Tanum,  and  tlie  COMSAT  earth  station  at  the  COMSAT  laboratories. 

The  first  of  these  is  another  standard  INTELSAT  earth  station,  the 
second  has  a smaller  dish  - but  still  with,  approval  to  access 
I the  INTELSAT  IV  satellite.  There  will  again  be  an  additional  line 

to  control  the  Tanum  SIMP;  the  COMSAT  one  may  be  controlled  via  the 
switched  telephone  network  if  necessary.  The  access  line  from 
[ ETAM  is  also  being  shifted  to  terminate  at  BBN,  in  Cambridge, 

Mass.ichusctts , on  a PDPll  Gateway  computer.  A similar  configuration 
will  exist  in  Kjelier  and  COMSAT . Now  there  will  be  a real 
Packet  Satellite  Network,  SATNET,  att.iciied  to  ARl’ANET  for 
dat.i  transmission  purposes  only  through  the  PDPlls  at  London , 
t-’.imbridge  and  Kjellc'r.  The  COMSAT  PDPll  will  be  attached  also  to 
their  ow.  IBM  363  for  measurement,  data  acqnisi tion  and  analysis. 


NCC  TIP 


Fig  7.1  Current  FSP  Configuration 


The  additional  9 bps  access  line  to  the  SIMPs  are  being  retained 
only  for  test  and  diagnostic  purposes;  they  will  be  removed  as  soon 
as  BBN  has  perfected  the  techniques  which  will  allow  test's  and 
diagnostics  to  run  through  the  Packet  Satellite  channel. 

The  new  configuration  will  radically  alter  the  experimental  situation. 
SATNET,  being  a four  earth  station  network,  will  allow  much 
more  realistic  tests  of  contention  strategies  with  the  channel. 

Because  identical  gateways  will  be  attached  to  all  the  earth  stations, 

It  will  be  possible  to  have  synthetic  traffic  generated  and  measurement 
data  acquired  in  the  Gateways.  Finally,  it  will  be  possible  to  change 
the  protocols  between  SIMPs  and  between  SIMP  and  Gateway  without 
any  need  to  remain  consistent  with  ARPANET  procedures.  At  present 
no  further  change  in  hardware  configuration  is  planned  during  the 
lifetime  of  the  experiment. 

7.3  General  Progess  During  1976 

This  is  the  annual  report  of  the  UCL  group,  and  not  the  other  PSP 
participants.  For  this  reason  it  is  not  appropriate  to  give 
lengthy  discussion  here  of  the  progress  of  the  other  groups.  During 
the  year  there  were  persistent  problems  with  the  satellite  channel 
itself,  particularly  in  the  contention  modes.  These  were  traced 
to  stability  problems  in  the  SPADE  experiment  under  the  novel  require- 
ments imposed  by  the  experiment.  Several  modifications  were  made 
both  to  the  earth  station  modems  and  the  Spade  - SIMP  interface  (SSI); 
these  have  alleviated  the  situation,  and  made  the  channel  useable 
for  experiments.  In  order  to  keep  close  control  of  the  channel, 
and  track  down  the  reasons  for  problems,  extensive  diagnostics 
were  built  into  the  SIMP.  Extensive  diagnostic  information  is  now 
passed  back  to  BBN  via  ARPANET,  to  be  analysed  there.  The  channel 
statistics  are  then  passed  to  all  the  interested  parties  on  a daily 
basis.  The  whole  data  acquisition,  analysis  and  distribution  of 
the  data  is  done  automatically.  In  addition,  new  SSI  units  are  being 
developed  by  COMSAT,  and  will  be  fitted  at  all  earth  stations  when 
the  Tanum  and  COMSAT  SIMPS  are  commissioned.  The  whole  area 
of  diagnostics  and  maintenance  have  received  great  attention  from 
BBN,  and  has  led  to  the  provision  of  the  extra  access  lines  of  Fig  7.1. 

There  have  been  extensive  measurements  by  the  UCLA  group  of  some 
of  the  simpler  strategies  for  using  the  satellite  channel. 


These 
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have  been  described  in  reports  from  Kieinrock's  group.  Extensive 
design  and  simulations  of  new  contention  strategies  for  using  the 
satellite  channel  have  been  carried  out  at  BBN , LINKABIT  and  UCLA. 

These  strategies  aim  at  using  the  channel  efficiently,  and  with  gccd 
recovery  from  errors,  overloading,  and  with  different  traffic  mixes. 
They  also  allow,  for  the  first  time,  the  attachment  of  priority  a.nd 
maximum  permissable  delay  on  the  data  packets.  Both  of  these  will 
bo  required  in  the  commercial  or  military  environment.  Implementati a.n 
of  these  strategies  in  the  SIMP  has  been  started  by  BBN , with  the 
aims  of  deployment  during  1977. 


Details  of  the  above  are  contained  in  a 
notes,  the  Packet  Satellite  Project  Workinc; 
may  bo  available  to  interested  parties  from 
notes  themselves. 


series  of  internal  working 
Croup  notes.  These 
the  authors  of  the 


One  gateway  PDP 1 1 has  been  installed  at  UCL  as  an  ARPANET  host  on 
the  UCL  IMP  and  also  on  the  Goonhilly  SIMP.  Gateway  code  has  been 

provided  by  BBN  so  that  incoming  packets  with  a particular  Internet 
header  (as  used  in  Chapter  5)  can  be  timestamped  and  passed  to  a 
program  being  developed  at  UCL.  There  arc  also  facilities  for  accepting 
and  forwarding  packets  generated  by  the  UCL  program,  to  either  the 
IMP  or  SIMP  attaclied.  Tlie  functions  of  these  UCL  programs 
will  be  described  in  Section  7.4.  A similar  PDP  1 1 has  been  attaci'.ed 
<is  a liost  to  ARPANET  at  BBN,  ami  can  be  used  for  testing  the  UCL 
code. 


7.4  The  UCL  Measurement  Tools  - An  Overview 

A high  level  traffic  generator/measurement  tool,  (i.e.  one  from 
outside  the  network  itself)  requires  that  the  network  under  measure- 
ment be  seen  and  interpreted  from  a host  level  point  of  view.  This 
has  two  immediate  consequences.  First,  the  experimental  traffic  must 
be  a realistic  model  for  traffic  generated  at  host  level;  second, host 
level  mtMSuremonts  must  be  oriented  towards  a user  measurement  of  net- 
work performance.  While  it  may  bo  possible  to  extrapolate  from  lower 
level  figures  for  variables  sucli  as  throughput,  some  variables  such 
as  network  response  to  user  demand  can  only  be  measured  at  host  level. 
Neither  of  these  requirements  depend  significantly  on  the  features  of 
<i  particular  network,  and  accordingly  much  of  the  following  discussion 
IS  couched  in  network  independent  terms;  in  any  particular  implementation. 
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the  network  interfaces  need  clear  specification.  On  its  o\/n/  such 
a tool  provides  a useful  means  of  assessing  the  o'^erall  performance 
of  a network,  but  would  not  tell  us  much  about  the  importance  of 
any  single  feature.  This  type  of  information  can  be  derived  by 
feeding  'realistic'  multi-user  traffic  through  lower  level 
measurement  tools  in  an  integrated  measurement  scheme. 

Bearing  these  considerations  in  mind,  there  are  three  important 
aspects  of  an  integrated  high  level  tool,  viz:  the  generation  and 

acquisition  of  the  traffic  to  be  measured;  the  control  and  variation 
of  traffic  generation  in  the  experimental  environment;  and  the  actual 
measurements  to  be  made.  These  are  discussed  in  Sections  7.5 
and  7.6. 

Three  main  traffic  patterns  are  recognised  in  this  experiment; 
each  of  these  traffic  patterns  may  be  varied  so  that  a wide  spectrum 
of  data  types  is  actually  covered.  The  three  main  patterns  are: 

(1)  High  data  rate  bulk  transfers 

(2)  Low  data  rate  steadystream  transfers 

(3)  Interactive  traffic 

In  the  SATNET  protocols  to  be  implemented  in  1977,  categories  2 
and  3 are  treated  as  similar  traffic  types,  for  purposes  of 
satellite  channel  reservation.  Priority  and  delay  can  be  specified 
however,  for  all  traffic. 

An  example  of  a high  data  rate  transfer  might  be  that  of  a file 
across  the  network.  The  message  generator  program  would  attempt 
to  push  messages  as  fast  as  possible  into  the  network.  The 
generator  may  try  to  transfer  a prescribed  number  of  bytes  through  the 
net  and  measure  the  total  elapsed  time,  or  may  just  transfer  as 
much  data  as  possible  in  a given  amount  of  time.  In  either  case  the 
system  will  measure  the  maximum  throughput  that  the  user  could  expect. 
Combining  this  traffic  with  other  controller  traffic  on  the  net  (sec 
below)  will  indicate  how  the  performance  deteriorates  with  interfering 
traffic. 

The  low  data  rate  steady  stream  transfer  covers  such  data  types  as 
voice  traffic;  where  the  total  amount  of  data  may  be  small  per  unit 
of  time  compared  to  a file  transfer,  but  the  messages  enter 

ft 
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aL  very  [jracLse  intervals.  Once  voice  tr.eas.njes  enter  tl'.e  network, 
they  must  be  delivered  not  only  at  a constant  rate  but  also  v.  ithin 
a specified  time  period.  If  for  instance,  a message  enters  the  net 
every  half  second,  it  must  be  delivered  every  half  second  at  the 
other  site;  'bunching'  of  data  is  not  permitted  here  (unlike  bulk 
transfer).  Much  real  time  data  such  as  voice,  facsimile,  telemetry, 
or  control  data  falls  under  this  category.  The  measurements  will 
consist  of  examining  how  consistently  the  messages  are  deliveifcd 
to  the  destination,  and  the  number  of  messages  that  arrive  at  the  des- 
tination within  a given  time  of  entering  the  system.  Here  too,  the 
effects  if  other  traffic  in  tlu-  net  will  be  measured. 

Interactive  traffic  is  the  most  difficult  to  simulate  and  the 
most  difficult  to  measure.  Typically,  the  user  sends  short  messaies 
of  variable  sise  at  variable  intervals,  and  receives  replies  consistin' 
of  one  or  more  linos  a short  time  later.  The  important  aspect  of 
tills  type  of  traffic  is  whether  the  messages  can  be  delivered  within 
some  threshold  time.  The  traffic  generated  by  the  program  will  be 
based  on  statistics  gatlicred  on  usage  of  the  ARPANET,  the  type  of 
messages  sent  and  the  typ»a  of  replies  received. 

The  ability  to  handle  all  these  traf  f ic  types  is  the  major  desiar. 
requirement  of  the  traffic  generator.  Tliis  requires  greater  flex- 
ibility til, ill  can  be  provideti  easily  by  .1  SIMP  level  traffic  general 

1 Traffic  Generation  and  Data  Accjuisition 

7.0.1  The  Environment 

This  is  a description  of  the  program  that  simulates  users'  inter" 
■iction  with  the  network.  Each  gateway  taking  part  in  these  ex- 
periments has  an  identical  copy  of  this  module,  which  consists  of 
throe  main  segments}  the  control  segment,  tlie  data  generation  segment 
and  the  data  reduction  seijmcnt . 

The  control  segment  .iccetits  cximmands  1 rom  >in  external  host, 
or  ,uiotlu>r  ijateway,  and  conti'ols  the  other  segments  of  the  program. 

The  qeni'rator  s i mu  1 .ites  tlu'  user's  1 n t cr.ict  ion . in  the  following 

discussion,  the  woril  'user'  will  denote  a simul.ited  user.  Messages 
.ire  generated  independently  for  each  user  and  the  messages  are  trans- 
mitted after  passing  through  a simple  flow  control  mechanism. 
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The  data  reduction  segment  will  accept  messages  from  any  gateway 
taking  part  in  the  experiment.  Pertinent  statistics,  selected  by 
the  ecperimenter , are  extracted  from  the  received  user  messages 
and  gathered  in  histograms.  At  present  intervals,  the  histograms 
are  sent  back  to  a data  collection  site. 

7.5.2  The  Traffic  Generator 


The  generator  is  controlled  by  a User  Traffic  Table  which  contains 
the  message  generation  details  for  each  user  being  simulated. 

Each  entry  in  the  table  describes  a separate  user  and  at  present  the 
table  has  32  entries  allowing  up  to  32  users  to  be  simulated  from 
each  gateway  at  a time.  The  user  traffic  table  is  loaded  by  the 
control  module.  The  table  can  be  loaded  or  modified  only  between 
experiments,  when  the  message  generator  is  not  using  the  table. 

Each  entry  in  the  table  contains  all  the  information  required  to 
simulate  a user,  although  the  number  of  entries  and  their  actual 
value  can  be  given.  For  instance,  the  experimenter  can  specify 
that  for  a particular  user  messages  are  to  be  transmitted  every 
10  seconds  + 2 seconds.  The  generator  uses  a random  number 
generator  to  select  the  actual  value  within  the  spread  constraints. 
The  most  important  paraimeters  that  can  be  set  are  shown  in  the 
following  table: 


User  Number* 

Mean  Message  Size* 

i Message  Size  Spread* 

j Mean  Inter  Message  Delay* 

1 

i Inter  Message  Delay  Spread* 

! 

: Next  Message  Number 

i 

1 

Next  Message  Length 
^ Scheduled  Departure  Time 

I 

Traffic  Type* 

Destination* 


A number  from  1 to  32 
I Mean  Size  of  generated  messages.  In 
j bytes. 

i The  Variation  allowed  in  message  sizes 
j The  mean  delay  between  sending  each 
j message. 

j The  variation  allowed  in  the  delay 
j between  messages. 

A sequence  number  inserted  in  the 
messages . 

I Length  of  the  next  message  to  be  sent 

! The  time  at  which  the  next  message 

I 

! will  be  sent. 

1 

' Interactive,  steady  stream  or  file 
i transfer 

* The  gateway  these  messages  will  be 
sent  to. 


Table  7.1  The  Important  Parameters  of  the  User  Table 


All  the  entries  marked  with  an 
loaded  by  the  control  program. 


• * • 


are  the  entries  that  must  be 
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whenever  a user's  message  is  transmitted  (and  at  the  beginning 
of  the  experiment)  the  data  generator  goes  through  a calculation 
to  determine  at  what  time  the  next  message  for  that  user  should 
be  sent,  and  what  length  that  message  should  be.  As  soon  as  the 
Scheduled  Departure  Time  for  a message  is  equal  to  the  current 
clock  time,  the  generator  attempts  to  transmit  the  message. 

However,  this  attempt  may  fail;  if  the  generator  determines  that 
the  gateway  is  unable  to  accept  the  message,  the  user  entry  is  put  in 
a frozen  state  until  the  gateway  is  ready. 

7.5.3  Expanding  the  Message 

Up  to  this  point  the  message  has  consisted  of  only  a few  entries 
in  the  User  Traffic  Table.  The  message  generator  actually  manipulates 
pointers  to  the  table  rather  than  moving  potentially  massive  messages 
around.  The  message  is  expanded  to  its  full  length  just  before 
transmission.  Each  mcssag£;  always  contains  the  following  information: 

Source  Gateway  Number 
User  Number 

Message  Sequence  Number 
Message  Length 
Scheduled  Departure  Time 
Actual  Departure  Time  * 

Traffic  Typo 
Destination 

The  entry  marked  * is  inserted  at  the  instant  of  the  message 
departure.  After  these  fields  have  been  inserted  the  message  is 
expanded  to  its  full  length  with  dummy  characters. 

Special  consideration  must  be  given  to  the  steady  stream  traffic 
type.  For  these  messages  it  is  important  that  they  are  sent  within 
a threshold  time.  If  the  delay  prior  to  transmission  exceeds  some 
threshold  val\ie  the  message  must  be  deleted:  there  would  be  no 

point  in  transmitting  it  as  it  is  already  out  of  date.  In  this 
case  the  message  is  deleted  before  transmission  and  the  generator 
proceeds  to  calculate  the  next  transmit  time  for  that  user.  For 
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stream  traffic,  the  delay  to  the  next  messaye  is  based  on  the  scheduled 
departure  time  of  the  previous  message. 

Using  the  Scheduled  Departure  Time  of  the  previous  message  as 
the  base  time  (whether  the  previous  message  was  cancelled  or  not) 
means  that  messages  are  generated  at  regular  intervals  regardless  of 
the  acceptance  rate  of  the  network.  With  other  traffic  types, 
where  the  current  clock  time  is  used  as  the  base  time,  the  input  stream 
can  'hiccup'  when  the  network  is  unable  to  take  any  more  traffic. 

This  is  consistent  with  actual  network  use.  If  the  network 
refuses  to  accept  a message  because  the  destination  host  is  not  rapid 
enough,  or  if  the  IMP  cannot  accept  more  traffic,  the  user  gets  any 
entries  rejected.  However,  this  simply  causes  the  user  to  wait  and 
try  again,  not  to  discard  the  messages  he  would  have  sent.  This 
is  also  true  of  file  transfers  which  always  try  to  transmit  as  fast 
as  the  netv/ork  will  accept. 

7.5.4  Data  Acquisiton  and  Reduction 

In  this  segment,  messages  are  accepted  from  other  gateways  in 
the  experiment  and  the  data  is  reduced  before  being  sent  on  to  the 
collecting  host.  The  data  reduction  segment  never  denies  entrv  to 
traffic  from  the  network.  It  will  accent  messaqes  from  anv  qateway 
at  any  time  and  in  any  sequence. 

As  user  messages  pass  through  the  satellite  network  to  the 
destination  gateway  they  are  timestamped  at  up  to  eight  different 
places.  By  inspecting  these  timestamps  at  the  destination,  the  time 
sper-t  by  the  message  in  various  parts  of  the  network  can  be  determined 
These  times  can  then  be  entered  in  histograms.  To  permit 
the  greatest f lexibility , a general  histogram  method  is  employed. 

The  experimenter  can  inform  any  gateway  (via  its  control  module) 
which  users,  from  which  source  gateways,  are  to  be  histogrammed. 

The  experimenter  can  also  select  the  timestamps  in  which  he  is  in- 
terested and  which  of  the  modes  are  desired.  In  one,  the  'successive' 
mode,  the  difference  in  a particular  timestamp  between  successive 
messages  is  used,  in  the  other  the  * difference ' mode , the  difference 
between  two  timestamps  in  each  message  is  used. 

Each  histogram  can  also  be  given  a 'lifetime'.  A lifetime  of 
one  minute^ for  instance, would  mean  that  every  minute  the  histogram 
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must  be  sent  back  to  the  coilectiny  site  and  then  re-initialised  to 
zeroes  for  subsequent  statistics  collection.  Thus  a series  of 
histograms  for  a user  can  give  a 'motion  picture'  view  of  the  users 
perf ormance . 

7.5.5.  Building-in  Response 

In  many  circiunstances  it  would  be  more  realistic  if  the  Data 
Acquisition  and  Reduction  segment  responded  to  some  of  the  user 
interactive  messages  sent  it.  In  this  way  the  segment  would  behave 
more  like  an  actual  remote  machine.  This  can  be  accomplished  by  the 
following  method:  As  well  as  the  information  currently  in  the  User 

Traffic  Table,  values  are  kept  for  the  generation  of  expected 
responses.  These  values  are  also  loaded  by  the  control  program. 

When  the  messages  are  sent  from  the  Data  Generator,  information  is 
included  in  the  m.essages  to  dictate  the  response  required.  Whenever 
the  Data  Acquisition  and  Reduction  segment  receives  a message  it 
inspects  this  response  field.  If  a response  is  required  the 
segment  creates  a message  in  the  normal  fashion  and  transmits  it. 

It  then  treats  the  received  messages  in  the  normal  way.  The 
message  that  is  sent  as  a reply  will  itself  get  reduced  at  the 
remote  gateway.  Such  messages  contain  a special  flag  to  indicate 
that  they  are  response  messages. 

Note  that  the  reply  is  controlled  by  the  Data  Generator.  This 
is  consistent  with  making  the  Data  Acquisition  Reduction  segment  as 
passive  as  possible,  so  that  it  acts  in  a slave  mode.  The  response 
informiation  would  have  to  include  the  delay  time  before  the  response 
message  length.  Only  one  message  is  ever  sent  as  a response. 

7.6  Control  of  the  Traffic  Generator  and  the  Experiment 

7.6.1  The  Junction  and  Structure 

The  traffic  generator  is  designed  to  be  controlled  from  any  host 
in  ARPANET.  Accordingly,  any  host  may  communicate  with  the  Traffic 
Generator  through  a well  defined  interface,  either  through  a resident 
controller  or  through  one  resident  elsewhere  in  the  net  which  accepts 
external  control.  In  order  to  maintain  the  integrity  of  this  interface, 
and  to  maintain  a clear  separation  of  the  control  functions  from  the 
measurement  functions  they  might  otherwise  affect,  it  is  better  that 
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ther.,'  be  no  controller  resident  in  a gateway. 

The  control  pathways  are  shown  in  Pig.  7.3.  Overall  direction 
IS  invested  in  an  experimental  host,  sitting  outside  SATNET,  in 
which  a controlling  process  (the  ' controller ')  resides.  This 
process  accepts  commands  interactively  or  from  a previously 
created  command  file,  validates  them,  and  passes  them  to  the  net. 

In  the  reverse  direction,  it  accepts  messages  from  the  net  and  acts 
on  them  where  necessary. 


Communication  with  the  net  is  via  one  of  the  participating 
gateways  (the  'service  gateway')  which  for  control  purposes  acts 
as  a relay.  All  control  messages  will  be  sent  to  the  gateways 
involved.  The  basic  control  functions  at  gateway  level  are: 

- to  initiate  an  experiment 

- to  start  and  stop  traffic  generation 

- to  change  traffic  distribution  or  simulate  protocol  paranetera 

7.6.2  Controller-specific  Features 

The  traffic  generator  is  controlled  by  a set  of  simple  commands 
which  will  be  common  to  all  controllers.  The  controller  can  be 
made  as  sophisticated  as  the  experimenter  requires,  and  the  following 
discussion  describes  some  features  of  the  UCL  implementation. 

The  controller  will  accept  commands  interactively.  flowever , 

It  will  also  execute  command  files  which  have  been  previously  pre- 
pared for  it  and  are  resident  in  the  same  host.  The  detailed  syntax 
cf  the  various  commands  will  await  implementation,  but  it  should  be 
possible  to  nest  files,  and  the  following  local  file  commmands  at 
least  should  be  available: 

KEAD^  f ilenamo:' 

W/\IT<  interval  > 

RETURN 

LOOP<  counter > 

7.6.3  Gateway-level  Functions 

The  broad  categories  listed  above  are  all  functions  requiring 


(before  executing  next  command) 
(from  this  file  level) 

(repeat  n times) 
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performance  by  the  gateway  traffic  generator.  At  this 
level,  conmands  will  be  provided  as  packets  arriving  on 
a particular  conunand  port  linking  the  gateway  to  the 
service  gateway  or,  in  the  case  of  the  latter,  to  the 
controller  through  ARPANET.  The  type  of  commands  are 
listed  below. 

i)  Initialisation 

Setting  up  an  experiment  will  involve  three  processes. 
The  first  is  to  establish  the  controller-service  gate- 
way relationship.  A request  to  control  an  experiment 
is  made  to  a listening  well-known  port  in  the  gateway. 
Each  gateway  in  the  experiment  has  such  a port,  and  if 
such  a request  is  accepted,  the  other  gateways  are 
informed  and  instructed  to  refuse  requests  until  the 
experiment  is  completed.  Similar  command  connections 
between  the  service  gateway  and  the  others  would  then 
be  set  up.  In  this  way,  the  whole  net  can  be  dedicated 
to  the  controller  (except  for  NCC  intervention) . 

The  final  stage  is  to  give  each  gateway  the  initialis- 
ation data  they  need  to  generate  traffic  and  collect 
data.  These  sections  will  be  identical  to  parameter 
change  messages  - accordingly,  they  will  be  discussed 
in  more  detail  there. 

ii)  Traffic  Control 

The  decision  to  commence  traffic  generation  and  to 
cease  it  comes  from  the  controller  in  an  explicit 
command.  This  command  applies  to  all  traffic  being 
generated . 

iii)  Parameter  Change 

The  parameter  cliange  mechanism  can  only  be  described 
in  general  terms.  The  significance  of  the  particular 
values  will  depend  entirely  on  the  traffic  type  being 
simulated.  The  Change  Packet  must  contain: 


- the  -siniulated  connection  number 

- the  n-.urber  of  t£)rarncters  tc  be  chancel 
and  for  each  paranieter 

- the  indent ifying  code 
-the  parameter  value 

The  information  in  a Triiffic  Description  packet  can  be  specified 
more  completely.  The  packet  contains: 

- i ho  number  of  simulated  connections,  and 
for  each  connection; 

- *'he  connection  numiier 

- tile  source  patoway 

- tlic  ti'affic  typo  (e.q.  steady  stre.r..,  f;le 
tranr  foi  ) 

- tile  cic:st  1 na t ion  yateway 

- the  destination  role  (e.g.  sink,  eclio, 

;:imul  at  cd  responst') 

- the-  me. in  packet  li.ngtn  at  source 

- liiti  variance 

- the  mean  cienerat  ion  interval  at  source 

- the  variance. 

- the  correspond i nq  figures  for  the  destinaticn 

- the  initial  packet  length 

- tlic  initial  transmission  interval 

iv)  Messages  to  control 

Messages  from  the  not  to  tlio  controller  will  usually  be 
succcss/fa  1 1 lire  messages  tii  response  to  a controller  request. 
Such  messages  might  include: 

- traffic  being  sent  (on  connection) 

- no  traffic  being  sent 

- protocol  parameter  change  accepted 

- ini t i a i i sa t ion  successful 

- access  [irohibited  (experiment  already  in 
proqres;0 
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T’he  State  of  Mie  Measurement  Tools 

A first  version  of  the  Controller  and  Traffic  Generator  have 
both  been  written  and  commissioned.  Both  are  still  undergoing 
modifications  as  our  experience  with  their  use  increases.  Some 
program.s  have  already  been  written  to  collect  the  data  from  the 
experiments  although  there  is  still  much  to  be  done  in  this  area. 
Since  the  gateway  software  arrived  from  BBN  only  during  December 
1976,  our  e.xperience  with  our  tools  is  very  limited. 

The  first  task  has  been  to  calibrate  the  performam:e  of  our 
gateway  and  test  the  generation  and  data  collection  aspects  of  the 
system.  For  this  we  arranged  to  have  the  generator  transmit 
messages  to  its  own  gateway.  Tnis  means  that  the  messages  are  not 
actually  transmitted  into  the  network;  they  are  turned  arour'.d  at 
a lov/  level  in  the  gateway,  and  are  handed  to  the  Data  Reduction 
Module.  Figures  7.4,  7.5  and  7.0  demonstrate  some  tyiiical  results. 
In  each  case  over  1000  messages  were  used  to  build  the  histograms 
shown . 

i’heso  histograms  are  important  for  future  exjier iments , as  tl'.ey 
demonstrate  the  performance  we  could  o.xpect  from  the  software  at 
jjresent  in  our  gareway.  For  instance,  the  round  trip  delay  of  an 
internally  looped  interactive  user  can  be  seen  to  be  about  48ms. 

This  is  higher  than  we  expected,  and  the  reasons  for  this  are  being 
investigated  at  the  moment.  BBN  expects  to  modify  the  software  they 
have  supplied  to  reduce  the  internal  processing  time  of  the  gateway. 

7.8  The  Application  of  the  Measurement  Tools  Planned  for  SATNET 

It  can  be  seen  from  Fig  7.3  that  the  gateways  are  at  the 
extrenuties  of  SATNET.  They  also  may  be  viewed  as  SATNET  hosts,  or 
even  as  SATNET  terminal  multijilexors . They  are  therefore  an  excell- 
ent place  to  be  doing  measurements  on  all  of  tlic  possible  modes 
of  use  of  SATNET.  Normally,  traffic  will  originate  at  one  point 
at  the  edge  of  tlie  network  designated,  or  a single  destination  at 
another.  The  usual  measurement  mode  will  be  to  generate  traffic 
at  me  gateway,  and  collect  it  at  another.  As  experimentation 
proceeds,  this  pattern  will  be  extended  to  generating  multiple 
streams  of  traffic  bound  for  different  destinations,  and  eventually 


to  be  generotia^t  'onourrent:.^.  t'.us  traffu  rroir.  several  yatewayb. 

The  need  foi-  one  gateway  to  con*^  .'<'1  ait  th.e  traftic  yeneraters  is 
obviously  useful  in  Lhis  nore  complex  pic* urc . However,  daca 
collection  onto  tj.ickiny  store-  can  be  done  more  easily  outside  the 
direct  SATNKT;  thus  the  necessary  software  and  the  processor  time 
to  aeai  witti  measurements  can  i>o  isolated  fron?  the  yateway  m.ichines, 
which  can  be  left  to  perfonu  the  basic  traffic  amuiation  task. 
Eventually,  however,  xt  r.ia  be  necessary  to  provide  local  aata 
collection  f.iciiities,  because  of  tae  a'n.sencc  of  sufficient  band- 
width to  drain  data  iway  from  SATT-3ET. 

SATN'ET  protocols  will  allow  prioa'Ity  and  d d.ay  i nformaci.cn  on 
traffic  to  bt  oncoc.ed  ^ a each  nfss.iye.  and  v;ill  act  on  this  inform- 
ation in  order  iny  leyuests  cli.;nnej  tran.sr.uss.ion.  No  problem 

exists  in  m.ik  i ny  tlie  cj,  i ‘ ev.'..iy  l.^aific  ■ :on>  a c.oi  s encode  this 
information  accordiny  t.  pre-set  puran.etei  s on  traffic  cliaracter- 
i St ics . 

The  small  station  particip.ition  and  conferencing  ap.plicac^-.i  will 
involve  measur eme.nt  issin  .s  wluch  art-  not  yet  properly  resolved 
and  will  be  relevant  only  in  .late  l'>77. 

The  SA'^'NET  SIMI'S  provide  the  ability  to  collect  status  information 
on  ijueues  and  ciianncl  behaviour  foi  every  few  seconds.  On  .in  even, 
more  det.iiJed  Level,  data  is  yt.'nern. tt’d  by  any  SIMP  'exception 
condition',  and  must  be  collected.  Assiiru  i<it  my  tnis  infoiir;.i  t ion 
into  data  anaL>sis  proyrLtms  is  a problem  still  to  be  tackled. 


STREAM,  INTERfvAuuY  LGOPEO,  MEAN=2B0MS,  lENGTH=40B,  STAND  ALONE 


Fig  7.4  Histogram  of  Message  Turnround  Times 


I 1 i ’ 'i  i . 


- 03  - 


b ; . < . /t'vv'()K  i\  ' . ; i ■ 1.  : ; i -i-N  ' . ■ 


w.i  introclacLion 

In  the  pluvious  annual  re^port  (Kirstoin , 1 976A)  , ve  dincus'-i  . 
number  of  network,  measurement  tools  v;hicn  wo  had  developed.  Th.eso, 
together  with  the  programs  needed  for  the  .inalysis  of  the  data 
gathered,  h.ave  been  developed  further  during  the  past  year.  Th 
development  work  is  now  at  an  end  and  dita  up  to  the  end  of  th..  rep- 
orting period  Ls  being  analysed.  This  work  and  1 results  are  de^-- 
cribed  fully  elsewhere  (Stokes  , 1077.A  ana  ; tones  , 107c;. ; . In  rhis 
chapter  we  give  a reviev/  of  the  work  an^l  soi.to  selected  results.  Oi 
course,  the  data  actiuisition  is  continuing  and  fur  ti.er  results  will 
be  presented  In  due  course;  hoviever,  :t  i ,s  ('xt'oeted  that  these  v/i  1 1 
piorely  com.pl  einent  the  significant  nmou:''t  of  data  already  gathered 
and  presented  hero. 

The  'lata  gathering  tools  wo  have  developed  give  us  i nf  ortuat  i ■ n "n 
four  types  of  usage.  First,  we  are  aljLO  to  monitor  the  pi  atu.s  of 
the  dial-up  ports  on  iiiO  Li.)ndon-TIP  and,  it  tlie  same  time,  prov  ■ do 
an  access  control  meciianism.  ihis  program  (QLUtS)  v/as  descri.'Cd  n 
som.e  detail  in  ( ni  rstein , 1 ‘..’7(jA  ) . It  requires  .i  dedic.tod  co’'u.’'t«r 
(PDP9B)  and,  due  to  ot.her  pressures  on  this  machine's  time,  we  hav,- 
not.  been  able  to  run  it  for  a sufficient  p-roportion  of  tin'  time  to 
cict  accurate  statistics  on  use  via  the  PSTN  (especially  as  our  sam;'’0 
'S  .itrongiy  biased  by  PDP9R  being  available  for  this  'puiposo  ilro-t 
''■xc  i u.s  i ve  ly  in  fho  mornings  and  at  v^’eekends,  if  at  all;  we  have  very 
J i.tt  1.0  dat.a  for  afternoons)  . Ouu  to  pii'essui  o I'n  machirv-  c iu-.  , no. 
uuc.h  m'lni.tor  1 ng  has  been  carried  out  during  t.lio  .second  half  of 
The  results  wc  have  obtained  arr>  discussed  .in  Section  8.2. 

Ttic  second  usage  we  are  able  to  monitor  is  that  through  PDP9,y. 

All  usage  of  the  RL  360/19  5 and  the  RSKb  GEC  4 080  is  via  this  mad'.  Ir.e 
since  the  PDP9A  system  monitors  all  interact iors  through  it,  we  ob- 
tain very  full  data  on  such  usage.  The  data  is  in  a similar  (al^hou-i 
si'jn  1 f leant  iy  different)  forn.at  to  that  of  P0P9D.  Wc  reerrd,  for  IT 
accessing  Rritish  machines,  the  machine  that  is  ire'c^sod , t'le 
machine  from  wliich  tlu'  access  was  m.irie , the  ports  used,  the  ident  - tj 
of  t)u'  users  and  the  account  used:  we  ar>  able  to  record  similar 
information  for  users  of  the  RL  machine  accessing  ARPANLT. 
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Much  of  the  usage  of  RL  through  the  TIP  is  from  UK  users,  mainly 
local  users  with  hardwired  terminals  or  a few  remote  users  with 
leased  lines.  In  general,  it  is  difficult  to  obtain  a consistent 
picture  of  leased  line  usage.  This  information  is  valuable,  for 
example,  to  PTTs  who  wish  to  know  whether  the  characteristics  of 
leased  line  usage  differ  significantly  from  those  for  PSTN  usage. 

Our  analyses  do  indeed  show  significant  differences  and  the  results 
are  given  in  Section  8.3. 

The  third  measurement  tool  runs  on  PDP9B  in  conjunction  with  the 
m.onitoring  and  access  control  program.  QUES  mentioned  above.  In 
general,  QUES  obtains  its  information  from  the  user  and  then  closes 
the  connection,  provided  the  user  is  authorised,  and  allows  him  to 
log  in  as  usual.  However,  it  is  possible  to  make  the  connection  for 
the  user,  anu  since  now  all  data  passes  through  the  PDP9B,  we  are 
able  to  make  a complete  transcript  of  the  interaction.  Due  to  the 
high  epu  overheads  involved,  we  have  only  used  this  technique  with 
one  host,  with  users  of  the  National  Library  of  Medicine  (NLM)  infor- 
mation retrieval  systems.  Analysis  of  the  data  thus  obtained  allows 
us  to  determine  various  parameters  of  usage  of  such  a system,  for 
example  the  distribution  of  system  keywords.  Although  the  tools  have 
been  developed  completely  in  1976,  the  number  of  runs  made  have  been 
very  few.  However,  we  plan  a week  long  experiment  early  in  1977 
which  will  provide  a significant  quantity  of  data.  Our  activities 
in  this  area  are  recorded  in  Section  8.4. 

Another  measurement  tool  is  totally  different  from  those  described 
above.  The  previous  three  were  all  at  the  user  level;  this  is  at  the 
line  level,  i.e.  measurement  of  the  IMP  subnet.  While  there  have 
been  extensive  measurements  of  the  subnet  by  the  Network  Measurement 
Center  (NMC)  at  UCLA,  these  measurements  have  relied  almost  entirely 
on  cumulative  statistics  gathered  by  the  IMPs  or  messages  traced 
through  the  subnet.  As  a result  of  these  measurements,  the  NMC  has 
identified  a number  of  significant  problems  in  the  subnet,  partic- 
ularly logical  errors  in  the  IMP-IMP  protocol.  However,  for  certain 
specific  purposes  (in  particular,  the  TCP  of  Chapter  5)  we  have  been 
interested  in  measuring  the  IMP-IMP  traffic  ourselves.  We  have  set 
up  some  fairly  elaborate  tools  to  make  this  possible,  but  they  have 
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been  used  only  vo"/  rarely.  ''neir  usaqe  Lis  enabled  as  lo  iderrily 
a number  of  specific  problems,  b'ath  viith  the  Tr'P  itself  and  with 
the  effect  of  the  point-to-point  satellite  line  on  the  IMP-IMP 
protocols.  This  work  is  described  in  Section  8.5. 

Finally  some  measurements  have  been  carried  out  of  the  perf  OT'man . - 
of  specific  Network  Control  Proarams  (NCP).  These  measurements  have 
been  performed  to  qive  us  yardsticks  for  compari nq  different  impien- 
entations.  They  are  liscusscd  in  Section  8.6. 

8.2  Monitorinq  of  P.STN  Hs.iqe 

The  techniijues  to  monitor  usaue  via  the  PSTN  were  described  in 
some  detail  in  the  previ  /us  annual  report  (Ki rstein , 1 916A)  and  some 
simple  results  were  presented.  Little  change  has  been  made  to  t;ic 
data  gathering  program,  QUKS,  but  the  analysis  programs  have  beer, 
modified  and  extenilfid.  In  iiddition,  we  now  have  results  for  over 
a year's  monitoring  and  present  these  here. 

For  ciarity,  at  tlit  ri.sk  of  some  repetition  of  the  previous 
report,  wc  now  describe  the  v;ay  the  Linal  results  are  obtained. 

PDP9B,  when  not  being  used  for  other  purposes,  runs  a program  callea 
QUES.  This  program  connects  itself  to  a nurr.ber  of  TIP  (curr- 

ently those  available  through  the  PSTN);  v/hen  a user  dials  in,  this 
breaks  the  connection.  On  noting  this,  QUES  immediately  seizes  tiie 
connection  and  interrogates  the  user  for  his  name  (not  checked),  iii s 
TIP  password  and  the  number  of  the  host  he  wishes  ti'  access.  Prov- 
ided these  are  acceptable  (he  is  allowed  one  error  on  each),  QUES 
closes  the  connection  and  allows  the  user  20  seconds  to  connect  to 
the  required  host.  It  then  attempts,  at  one  second  intervals,  to 
reconnect  to  the  user  and  only  succeeds  when  he  closes  the  ccnnect- 
ion  to  the  remote  host.  It  then  asks  him  the  next  host,  number 
required  and  so  on. 

For  every  interaction,  it  pirints  data  onto  a paper  taj..e  log , toqet  he- 
with  other  information  (e.g.  every  half  hour,  it  prints  a miessage 
stating  it  is  still  monitoring) . This  paper  tape  is  then  sent  to 
the  RL  360/195  and  analysed  by  a program  called  XFSTATS  (Stokes, 


1976B).  This  is  written  in  Babbage  (Stokes , 1974 ) and  makes  exten- 
sive use  of  the  facilities  in  its  system  library  ( Stokt s , 1 9 773) . 

The  analysis  consists  of  two  phases.  The  first  is  to  reduce  the 
output  to  a canonical  form.;  this  consists  of  reducing  each  total 
interaction  to  a single  line  and  tidying  up  in  t'  e case  of  system 
crashes.  Considerable  error  checking  is  performed  and  the  output 
may  be  assumed  to  be  error  free.  The  second  phase  is  the  actual 
analysis;  in  this,  the  data  is  read  into  core  in  a specified  structure 
and  this  structure  is  traversed  in  the  requisite  fashion.  In  this 
manner,  we  are  able  to  analyse  usage  of  the  London  TIP  via  the  PSTN 
in  some  detail.  To  be  specific  the  analyses  available  are: 

Times  monitored 

Surnames  used  for  each  Ident 

Number  of  logins,  connect  time  and  number  of  hosts 
used  for  each  Ident 

Number  of  logins,  connect  time  and  number  of  users 
for  each  host 

Matrix  of  connect  times  for  each  host  number/ ident  pair. 

For  simplicity,  the  results  are  available  in  graphical  or  tabular 
form. 

We  have  a considerable  amount  of  data  for  the  period  July  1975 
to  July  1976  and  it  is  upon  this  that  we  concentrate.  Before  that 
date,  although  password  validation  was  effective,  we  did  not  proh- 
ibit access  for  illegal  users.  After  July  1976, we  have  done  relat- 
ively little  such  monitoring  due  to  other  pressures  on  the  computer. 

Over  the  year  in  question,  we  monitored  the  TIP  for  about  50& 
of  the  time  but  much  of  this  time  was  at  weekends  and  in  the  evenings 
when  usage  was  extremely  low.  In  addition,  the  amount  of  monitoring 
performed  varies  significantly  from  month  to  month.  Figs  8.1  and  8.2 
show  this  variation;  the  former  shows  the  breakdown  by  hour  of  day, 
the  latter  by  month.  The  largest  usage  was  by  the  British  Library 
research  groups  accessing  the  National  Library  of  Medicine  data- 
bases. Hov/ever,  this  use  is  biased  because  the  usage  of  NLM  coin- 
cides almost  exactly  with  the  times  we  monitor. 
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On  the  other  iiand  most  university  usage  occurs  in  the  late 
morning  or  afternoon  - because  of  university  lectures.  Many  of 
the  more  activ'e  users  (Blacknest,  Salford  U and  the  High  Energy 
Physics  Users)  access  via  the  RL  360/195  or  a direct  leased  line 
to  the  TIP.  Thus  their  usage  is  not  reflected  in  the  figures. 

The  overall  pattern  of  usage  monitored  over  the  year  is  shown  ir. 

Figs  8.3  and  8.4.  The  results  are  examined  in  detail  in  (Stokes, 
1977A).  Another  type  of  statistic  of  interest  to  PTTs  and  the 
systems  manager  is  that  of  port  usage.  Figure  8.5  shows,  for  e.xarr.ple, 
the  number  of  logins/'nour  monitored  during  specific  periods  of  trie 
day . 

» 

8.3  Measurement  of  Usage  via  PDP9A 

PDP9A  frcntends  a number  of  computers  onto  ARPANET  as  has  been  dis- 
cussed in  Section  2.  At  the  present  time  those  are  the  RL  360/195 
and  the  RSRE  4080.  All  traffic  through  PDP9A  is  monitored.  There 
are  two  types  of  traffic,  and  hence  of  measurement.  The  first  is 
similar  to  that  of  the  QUES  of  Section  8.2;  instead  of  monitoring 
lines  to  the  TIP  from  the  PSTN,  we  monitor  terminals  attached  to 
the  RL  360  (either  directly  or  via  a workstation).  The  second  usage 
is  the  converse,  the  usage  from  ARPANET  accessing  the  RL  360  or 
RSRE  4080  as  a host. 

Tlie  analyses  performed  are  similar  to  those  for  QUES,  although 
in  addition  system  performance  is  monitored.  For  users  to  ARPANET 
through  the  PDP9,  the  analysis  available  is  identical  to  that  for 
QUES  (since  we  are  considering  essentially  the  same  interactions, 
that  is  a user  connected  to  a host  on  the  London  IMP;  in  one  case 
the  TIP,  in  the  other,  PDP9A)  with  the  single  exception  that  the 
user  is  identified  merely  by  his  terminal  address.  For  usage  from 
ARPANET,  again  similar  data  is  noted  as  in  Section  8.2;  now,  however, 
the  source  host  and  360  user  IDENT  are  noted  instead  of  the  destin- 
ation host  and  user  password  of  Section  8.2.  On  a system  performance, 
the  information  collected  is  the  time  at  which  each  machine  (PDP9A, 
IMP,  RL  360  and  RSRE  4080)  went  down  (scheduled  and  unscheduled)  and 
came  up  again.  Each  occasion  of  receipt  of  an  incorrect  protocol 
message  is  noted.  In  addition  the  start  time,  end,  source  and  des- 


101 


t'iq  8.4 


Usage  of  Various  ARPANET  Hosts 


tination  of  each  file  transfer  is  also  noted. 


From  the  performance  data  noted,  we  derive  figures  for  the 
Mean  Time  Between  Failure  (MTBF)  and  the  Mean  Time  to 
Repair  (MTTR) , and  the  frequency  of  erroneous  protocol 
messages  (and  their  source) . From  the  data  collected 
on  ARPANET  usage  from  the  RL  360,  we  derive  results  identcal 
to  those  of  Section  8.2,  with  terminal  Location  replacing 
user  ID.  In  many  cases  this  is  more  reliable,  because  a 
terminal  is  used  exclusively  by  a specific  oroup.  From  the 
data  collected  on  ;L  3t0  ard  RSRE  usage,  again  the  results 
derived  are  identical  in  form  to  those  of  Section  8.2;  now  the 
service  host  and  RL  360  ID  are  used  as  identifiers.  The 
file  transfers  are  analysed  in  some  detail.  For  files  trans- 
fe>"s  between  the  PDP9  and  ARPANET,  we  list  the  number  of  tilss 
by  the  Ident  of  the  person  initiating  them,  and  the  elapsed 
time  and  direction  of  each  file  transfer.  Finally  histograms 
are  derived  of  port  usage;  for  each  machine,  the  distribution 
of  port  usage  as  a function  of  time  is  presented. 

On  examining  the  global  statistics  over  1976,  we  find  that 
the  availability  of  all  the  machines  is  high.  The  number  of 
times  the  PDP9  crashed  (847)  is  also  high  but  on  examining  the 
data  more  closely  it  can  be  seen  that  on  5 occasions,  a 
single  fault  (e.g.  a host  on  ARPANET  sending  illegal  messages 
or  a drum  fault  on  PDP9A)  manifested  itself  and  caused  the 
system  to  crash.  If  this  occurred  at  nj.ght,  with  no-one  present, 
the  auto-restart  mechanism  would  enable  the  crash  to  recur 
at  intervals  of  a few  minutes  until  corrected,  thus  giving 
rise  to  a high  number  of  crashes.  307  crashes  were  due  to 
this  and  hence,  the  real  number  should  be  545  giving  a MTBF 
of  over  9 hours. 

Another  global  statistic  is  the  number  of  times  all  ports 
were  in  use.  PDP9A  has  five  ports  to  ARPANET  and  on  many 
occasions  (155  times  during  the  year),  these  were  fully 
occupied.  From  PDP9a  to  the  RL  machine,  there  are  only  three 
ports  available  to  ARPANET  users  (two  other  ports  are  avail- 
able ; the  first  is  permanently  connected  to  a specific 


local  device,  and  the  second  is  used  for  traffic  in  the 
other  direction)  . The  number  of  times  a fourtli  user 
tried  to  login  and  was  rejected  was  358.  Fig  8.6  shows 
the  total  number  of  logins  to  the  PDP9A  during  1976. 

On  examining  the  connection  statistics  (Fig  8.7)  we 
see  that  the  greater  part  of  usage  of  the  RL  360  is  made  by 
the  UCL  research  group  (INDRA)  and  the  Blacknest  Seismic 
Research  Centre,  who  have  set  up  a seismic  database  which 
is  updated  daily.  The  relatively  small  amount  of  usage  by 
other  groups  is  a reflection  of  the  nature  of  host-to- 
host  use  of  the  networlt;  such  use  tends  to  be  concentrated 
and  concerned  with  the  routine  running  of  jobs  or  the 
exchange  of  files,  compared  with  dialled-up  terminal  access, 
which  is  often  concerned  with  communication  and  exploratory 
work.  Host-to-host  access  therefore  tends  to  be  of  much 
shorter  duration  than  terminal  access. 

8.4  Characteristics  of  a Specific  Host 

A part  of  our  project  has  been  to  provide  access  to  a 
number  of  British  Library  (BL)  centres  accessing  the  MEDLINE 
and  CANCERLINE  databases  on  the  NLM  IBM  370s  and  to  monitor 
such  access.  Some  monitoring  can  be  performed  by  QUES;  other 
monitoring  is  done  by  a program  called  MEDLINE  which  runs  in 
conjunction  with  QUES. 

If  a user  specifies  his  required  host  as  147  (the  TIP  to 
which  NLM  is  connected)  or  NLM  he  is  not  released,  as  usually 
happens  with  QUES,  but  rather  is  transferred  to  MEDLINE. 

This  program  maintains  status  information  about  NLM  and 
informs  the  user  of  the  current  status.  If  satisfactory, 
it  is  assumed  he  wishes  to  proceed-  if  not,  he  is  asked  whether 
he  wishes  to  wait  while  a connection  is  attempted. 

The  program  attempts  to  connect  to  the  five  ports  in  turn, 
and,  if  it  is  able  to  do  so,  logs  the  user  in  (using  either 
an  Ident  specified  by  the  user  or  a free  one  chosen  by  the 
program  out  of  the  group  allocated  to  UK  users) . 
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It  then  asks  the  users  for  his  oasswor-i.  and  from  this  stage 
on.  permits  a transparent  connection  with  a few  exceotions. 

These  exceotions  cover  three  areas.  The  first  is  that  simole 
control  characters  are  permitted,  to  allow  slight  local 
editina  of  the  current  inout  line;  the  second  is  that  the 
user  is  given  access  to  certain  data  held  in  the  PDP9,  e.g. 
the  total  connect  time  of  the  current  interaction;  the  third 
is  that  some  of  the  verbosity  of  the  NLM  dialogue  is  removed. 

Up  to  this  point,  the  program  merely  acts  as  a Network  Access 
Machine.  However,  if  the  monitoring  option  is  selected,  a 
direct  transcript  of  the  conversation  (or,  more  specifically, 
a transcript  of  all  conversations  in  progress,  datestamped 
and  with  a channel  identifier,  multiplexed  together)  is 
sent  to  the  current  monitoring  device,  usually  magnetic 
tape,  but  disk  if  required. 

This  tape  is  then  sent  to  the  RL  360  for  analysis.  The 
analysis  consists  of  two  phases;  the  first  is  to  demultiplex 
tne  separate  conversations;  the  second  is  to  examine  character- 
istics of  tie  usage,  for  example,  occurrences  of  system  keywords. 

At  the  oresent  time,  we  have  considerable  data  on  NLM  usaae 
from  DUES  but  little  from  the  MEDLINE  program  due  to  various 
technical  oroblems.  A week  long  experiment  is  planned  in 
early  February  1977  and  the  results  from  this  will  be  reported 
later.  The  results  obtained  from  OUES  provide  some  interestino 
insiahts  into  usage  of  NLM.  Because  of  the  mode  of  operatioii 
of  QUES,  some  connections  are  recorded  when,  in  fact,  no 
real  connection  was  made.  This  is  due  to  a connection  being 
made  to  the  appropriate  port  on  the  NBS-TIP  correctly,  but 
NLM  itself  being  down.  Removing  these  from  the  statistics 
(and  also  unfortunately  some  very  short  genuine  inter- 
actions), we  find  that  the  average  time  per  session  is  just 
under  23  minutes  (see  Fig  8.7)  indicating  that  most  users 
perform  one  search  per  session;  in  one  session,  however, 
thirteen  s'^arches  were  performed  in  nearly  two  hours,  involving 
the  output  of  over  20,000  characters  from  NLM. 

8.5  Networx-Level  Performance  Measurement 
8.5.1  Introduction 

In  previous  years  we  have  constructed  simple  measurement  tools 


to  look  at  particular  throughput/delay  characteristics  for  traffic 
between  the  PDP9s  and  other  ARPANET  hosts,  or  to  look  at  particular 
improvements  in  the  ARPANET  Network  Control  Program  (NCP)  that 
we  were  thinking  of  making.  We  found  usually  that  the  effort  to 
get  reasonable  measurements  was  not  negligible,  and  moreover  we  were 
left  with  a data  reduction  problem  to  solve  in  each  case.  Unlike 
the  TCP  evaluation  effort  of  Chapter  5,  we  were  not  prepared  to  build 
powerful  general  m.easurement  tools,  as  the  set  of  measurements  we 
wanted  to  make  was  a changing  requirement  from  time  to  time. 

The  introduction  of  SWITCH  (Chapter  3)  was  a good  opportunity 
for  designing  a throughput/delay  tool  that  could  be  used  equally 
to  look  at  throughput/delay  to  destinations,  or  at  a particular  NCP 
performance.  The  SWITCH  interface  allowed  the  traffic  generator  to 
look  like  a network  itself,  and  to  be  accessible  for  running  exper- 
iments as  a similar  interface.  It  was  now  justifiable  to  put  effort 
into  constructing  automatic  generation,  collection,  reduction,  and 
graphing  facilities  into  the  tool,  because  of  its  generality  of  use. 

Certainly  in  our  context,  the  usefulness  of  this  measurement 
facility  is  akin  to  a performance  measurement  tool  in  an  operating 
system.  We  wish  to  evaluate  possible  improvements  in  our  network 
support  software,  to  monitor  changes  in  subnet  protocols  or  topol- 
ogy over  a period  of  time  in  order  to  detect  any  effects  which  may 
not  have  been  anticipated.  Since  in  our  system,  we  are  supporting 
host  connections  by  RJE-type  protocols,  we  wish  to  gather  perfor- 
mance figures  on  these  hosts,  particularly  where,  in  the  ULCC 
attachment,  we  are  using  half-duplex  protocols  with  low  throughput 
potential.  In  the  case  of  EPSS,  this  tool  may  be  useful  in  provid- 
ing thorough  statistics  on  the  switching  exchange  availability  from 
a user  point  of  view.  A facility  of  this  type  for  performance  meas- 
urement is  a useful  additional  tool  for  the  design  of  a virtual 
circuit  mapping  gateway.  A full  description  of  this  measurement 
tool  is  given  elsewhere  (Williams , 1976) ; here  we  summarise  the 
tool  facilities  and  some  preliminary  measurements. 

8.5.2  Tool  F’acilities 


A traffic  generator  capable  of  varying  frequency  and  length  of 
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message  generation  resides  on  the  SWITCH  gatev/ay  as  r 'network' 
address.  It  is  capable  of  generating  to  a number  of  destinations, 
or  on  a number  of  connections  to  the  same  destination  simultan- 
eously. Traffic  is  timestamped  on  generation , and  on  receipt  of 
echoed  messages,  allowing  overall  delay  to  be  measured  by  halving 
round-trip  time.  Additional  timestamps  can  be  inserted  at  the  NCT 
level  when  necessary.  The  method  does  require  an  echo  process  to 
be  used  at  the  destination;  for  hosts  it  is  possible  to  get  round 
this  by  using  a protocol  positive  acknow]  edgement  signal  to  m.easure 
delay.  If  necessary,  an  eclio  process  can  be  written  at  the  destin- 
ation to  allow  additional  timestamping. 

The  returned  m.essages  have  timestamps  removed,  and  history 
records  are  written  to  magnetic  tape  in  an  IBM-compatible  format. 

An  offline  analysis  program  takes  the  records  and  formats  them 
suitably  for  input  to  the  BMU  graphing  package  (a  UCLA  statistics 
package  commonly  available  on  300s). 

8.5.3  Measurement  Results 

At  the  tine  that  the  measurement  tools  were  completed,  only  the 
ULCC  CDC  6400  connection  was  functioning  to  the  SWITCH  interface; 
the  other  hosts  and  network  connections  to  SWITCH  were  still  under 
development . 

The  CDC  6400  proved  a useful  and  interesting  first  application 
of  the  tool,  as  the  problems  of  achieving  reasonable  throughput 
with  half-duplex  protocols  are  well-known,  and  we  wished  to  confirm 
this  behaviour  on  our  own  connection.  V^c  also  wished  to  examine 
the  polling  frequency,  and  message  processing  delay  at  ULCC,  as 
'■/ell  as  examining  ithe  behaviour  of  our  software  which  had  not 
previously  been  used  in  other  than  a test  setup. 

Measurement  consisted  of  generating  messages  at  fixed  intervals 
to  bo  sent  to  ULCC.  As  we  had  no  echo  program  available,  we  used  the 
protocol  acknowledgement  as  an  indication  of  delay  to  and  from 
the  CDC  6400.  Measurements  were  carried  out  both  at  peak  times 
and  at  night;  to  facilitate  control  over  measurement  periods. 
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tile  sottwcire  way  exten.ted  to  allov;  automatic  shutdown  at  a time 
given  in  the  yet-up  oi  an  experimental  run. 

The  resuity  showed  a fairly  consistent  pattern  of  throughput/ 
delay  as  follows: 


mean  time  for  a message  to  CDC  6400 


and  its 

ac know lodgement : 

2.3  2 

secs 

time  Jn 

the  PDP9: 

0.97 

sees 

time  in 

the  CDC/PDP9  software: 

0.015 

secs 

Subtracting  the  third  figure  from  Idle  second  siiows  a considerable 
time  spent  in  the  PDP9  outside  the  actual  protoi.'ol  driver  for 
the  200UT  emulation.  Although  in  the  PDP9  system,  messages  do 
get  buffered  to  backing  store,  this  time  i.  s obviously  excessive. 
We  were  able  to  track  down  a scheduling  error,  v;hich  accounted 
for  most  oi  this  delay  (the  PDP9  processes  are  all  currently 
cLocx-driven)  . Timt'  in  the  proLixiol  handler  at  0.015  secs  would 
appear  reasonaiile  - t.he  accuracy  of  our  measurement  clocks  is 
insufficient  to  analyse  this  figure  more  precisely. 

Subtracting  the  second  figure  from  the  first  gives  the  time 
outside  the  PUP9  as  i.bS  secs.  The  24  byte  test  messages  used 
for  these  measurements  are  considerably  swollen  by  addressing, 
header,  and  padding  characters  (the  CDC  puts  out  such  things 
as  screen  clear  characters)  and  the  calculated  transmission 
time  for  messages  (both  directions)  is  0.51  secs.  In  addition 
there  is  a modem  switching  time  associated  with  tlie  use  of  a 
half-duplex  protocol.  Time  spent  in  the  6400  would  therefore 
appear  to  be  slightly  in  excess  of  one  second  per  message. 
Although  the  measurements  were  very  consistent,  occasional  delay 
peaks  as  high  as  7.37  secs  were  recorded. 

Throughput  figures  wore  calculated  for  both  single  and  triple 
connection.s  to  the  CDC  6400  . Triple  connection  is  achieved  in 
this  implementation  by  emulating  three  200UT  terminals  in  multi- 
dropped  mode.  The  CDC  polls  infrequently  addresses  not  currently 
active,  so  the  additional  overhead  of  using  the  multi-dropped 
software  is  marginal.  However  it  is  interesting  to  compare 
whether  the  sum  of  tiiroe  loaded  connections  compares  with  the 
throughput  on  a single  connection. 
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while  for  cuuulative  throu'iiipiir  ^or  three  conneetions  v/aa  LAi 
bps.  The  improved  ficjuia?  resuJ  ts  from  of  the  'dead'  t:r;e 

waitinq  for  the  6400  to  retarn  the  nessaije  in  a single  connection. 

TaKiiv  into  account  che  oveiiiead  bytes,  actual  throughput 
IS  375  bps.  Thi.s  fieure  is  very  j cv;  for  t dlOC  bps  line, 
highlights  the  problems  of  iia  1 f “>iup‘lex  :r.uiti-drop  orotoccls; 
it  i.s  surprising  that  thesi>  ar  ' st'li  being  used  in  contexts 
where  a full-duplex  j^rotocol  is  (iemandori.  >af  course  a protocol 
of  this  type  will  il'ways  i'.ave  i maiket  in  c.^s^,-:  ■' f distributed 
low-activity  tcrn.inajs,  where  no  '.:\',ckra -cw  i t crii  ng  caoability  is 
av.jilablc,  or  where  the  capit.ii  cost  (if  attaching  to  a packet- 
switch  network  is  too  inch. 

While  this  rot  a s;""er.er.i  to’il  nas  tjnly  lieon  used  to  UI.CC,somo 
conclusions  can  be  diaiv/n  ^ilrcady.  Firstly  ti*w  BMD  t'ackaae 
combines  extensita:  .>t.tia  st  lea  1 ui'ocessing  caoability  v/it!i  very 
limited  graplunv)  capabiJ  i ties . For  the  kind  of  data  gntiie’'ed 
in  these  moi.isurcr..jnts , ’imilod  data  redu>'tion  -with  better  graphing 
would  be  more  appropri.Oi  . Prolialjiy  a suecifiv:  f triiaiting 
program  calliiuj  t ic- a:  li.- . 1 ott  i n*':  package  will  be  nei’olopcd  in 
t!ie  future.  Seo,n(;iy,  -'ar  oxporionce.s  in  /M\F.-\hFT  '.ast  year  siiowed 
that  host  cchoiiKj  facilitie.s  es  'ipecified  in  the  host  protccnl 
were  not  ajgiropr  iate  to  tliis  .so'  t of  measureincni  . T.M.K/LIl-K 
subsysti'nii.  oii  T«.  ncx  .vould  scum  a much  mo!  '.'  appropriate  eciio 
method,  and  pri- limi  nary  tests  show  tiiat  this  will  jirohably 
be  the  nio.,!  appi opt  late  mettioti  to  use. 

Talk/Link  sub.systcms  are-  designed  t<  allow  several  terminal 
users  to  talk  to  each  other,  and  operate  by  copying  the  user's 
line  to  another  terminal  connt'ction.  Copyintj  hero  operates 
at  a higiicr  priority  titan  echo  sockets,  .and  therefore  can  be 
adapttnl  ri()re  easily  to  the  mode  of  messapio  reflection  required. 

h . ()  biru;  Nkui.su remen  t s 

'I'lii  mi  as.urement  s describee  in  ' ae  premilinq  sections  .trc  cntirei 
.it  till'  user  ievt  1 ; this  is  only  one  of  a number  of  levels^  at  v;hicn 
measut  • 'menl  s m.iy  be  perfornii'd.  Another  level. 


wibu  whict'i  tills 


soc_io.-'.  ii<  v.’cn-'c.'i  nc'i , i i nat  ul  the  line.  V.’e  j.avf  .1 

['t  i;  : ■ ...i'.i  rur.iiiny  ti  wn  i.ch  can  iroasare  the  tr.itiie  bi.'tween 

i;uv  IMl’  anJ  t i'.c  .■djanent  LMP  (more  specifically  it  copies  data  headers 
fruM  tne  Line  Liotwoen  oui  li'n'  and  the  moden)  . The  .headers  are  copieu 
ont<.i  naqnetij  tape  for  later  analysis  on  the  UC  3h0/65. 

no  serious  proi/Lem  that  arises  is  tnat  of  data  tnrou'jhput . 

Tut-  line  is  0 . 6K  bps,  w’njc'ii  means  t.nat  datu  can  arrive  a*  one 
cni:  actor  every  ) . 8 ;us . Si.nce  t'U'  c-mir.nnicat  ion  adaptors  operate 


uncicr  progr.in.  intenupt. 

"or 

packt  t - 

ano  tnc 

mi.nimum  packet 

size  is  4 ch.,iiacte»':.  - t 

In  Tc' 

i 

, post.ible 

crisis 

time  of  j ii:S . 

I'ne  only  wa'>-  to  .icliievc 

th  IS 

t’nrouq.ipait  is 

to  use 

a circular 

1 utter  pool  (currently  three  but  tors  per  line)  which  is  used  for 
d,,  t,.  x.t  from,  the  1 i ,10  ^na  dat.a  out  t.-  the  t apt  . However,  there 
woutd  be  serious  proLlo::.;;  in  att  en-.pt  i nq  to  record  data  from  a line 
of  considerably  tiighei  oandv/idth. 

The  analysis  proyram.  e i l ecti  vel',-  moiiels  ti'.c  network  protocol 
implementation.  Lt  perm.t.s  analysl.-,  at  any  (or  all)  of  tne 
three  levels  of  prot'’C^'l:  i 1 MP , ilost-Hi.st  or  Iscr.  Tite  volume 

of  data  whic’.t  is  m-  nite-red  .i  ■:  i ntromeiy  h,.yn.;  for  exampLe,  in  at. 
hour,  tv;o  meyab^  te.-  '>1  routina  data  v/h  1 ch  enables  the  T.MPs 

to  alter  dynaitii  ily  liieir  t out  lay  c. doles)  .iie  recorded.  Most  of 
the  data  is  uL  tiic  IMP-I.Ml’  leve!.  .hn  example  of  the  type  of  data 
which  can  bo  derived  is  shown  in  diy  '6.0.  Here  we  sh.ow  a histogram 
of  the  types  of  p.ick*  t ..;  a function  of  time;  denotes  routing 
piclots,  I iMP-lMP  control,  li  is  Host.-ilost  Protocol,  and  D is  Data. 

Since  tlic  information  of  interest  is  often  about  a specific 
connection  or  about  a s}jccific  facet  of  a protovol,  the  analysis 
programs  were  written  acconiingiy.  In  a typical  analysis  session, 
thci  e arc  two  (or  more)  runs.  Tlie  first  scans  the  tape,  and  produces 
a table  of  contents  fot  the  tape  including  suen  information  as 
tile  duration  of  measurement  and  Llie  amount  of  data  analysed.  The 
soccjnn  ind  sulisecfuent  runs  g i vt-  rqiecilic  details.  'ihe  various 
analyses  that  arc  pos.siLlc>  arc  specified  in  detail  in  (Treadwell, 
1977).  The  follewing  are  .some  p.irtic'uiir  interest. 

The  first  is  the  "Main  Jo<j"  whicli  is  a voriial  description  of 
eacli  packet  on  the  line  (see  Fig  8.10)  although  tiui  new  version 


may  decide  to  omit  certain  types  of  packet,  such  as  routing 
packets.  These  may  be  analysed  separately  tc  determine,  for 
example,  the  instantaneous  state  of  the  network,  as  seen  by  the 
UCL  IMP. 

In  addition  to  the  logs  we  are  able  to  produce  five  types  of 
graph.  One  example,  a plot  of  the  delay  between  the  sending  cf 
a message  and  the  RFNM  (Ready  for  Next  Message)  as  illustrated 
in  Fig  8.11). 

This  measurement  tool  has  proved  valuable  on  a number  of 
occasions.  Our  preliminary  results  revealed  tv.'o  interesting  aspects 
of  the  London-Norway  line.  First  the  routing  messages  accounted 
for  over  60%  of  the  total  data  traffic,  even  when  the  latter  is 
high.  Secondly,  the  number  of  retransmissions  was  found  tc  be  veri- 
high.  This  is  caused  by  the  large  amounts  of  seism.ic  data  being 
injected  at  Norway,  about  2 . 4K  bps  average,  and  the  limited  number 
of  packets  that  can  be  outstanding  at  any  one  time.  The  com.binaticr. 
of  these  facts,  with  the  long  transit  tine  over  the  satellite 
circuit  and  the  low  bandwidth  of  the  UCL-Norway  and  N’or-way-Us 
lines,  leads  to  the  Norway  IMP  being  swamped  and  rejecting  data 
until  it  has  freed  some  buffers.  This  explained  some  anomalous 
results  encountered  with  our  TCP  experiments  (see  Section  5.3.2), 
when  it  was  noted  that  contrary  to  expectations,  increasing  the 
"window"  size  past  a certain  threshold  actually  reduced  throughput. 

Another  point  of  interest  is  that  when  a host  on  our  IMP  comes 
up,  it  attempts  to  send  "resets"  to  every  ottier  host  on  the  network. 
Due  to  the  mode  of  operation  of  the  protocols  this  results  in  the 
sending  of  throe  times  as  many  messages  into  the  network  and  this 
again  causes  the  Norway  IMP  to  flood. 

Thus,  this  tool  is  a very  valuable  addition  to  our  repertoire 
of  measurement  tool  and  provides  a flexible  means  cf  examining  the 
lowest  level.  It  is,  however,  most  useful  in  areas  where  we  have  a 
requirement  to  examine  a specific  type  of  behaviour,  owing  to  the 
vast  quantity  of  data  generated. 
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CHAPTER  9 EXPERIENCE  WITH  UK  USE  OF  ARPANET 


9.1  Introduction 

Use  of  ARPANET  from  the  UK  during  1976  has  largely  followed  tiie 
pattern  that  was  becoming  established  in  1975;  there  is  more  host- 
to-host  use  for  collaborative  projects  between  UK  and  US  researcr. 
groups,  and  less  terminal  access  for  more  casual  use.  Thus  we 
were  able  to  reduce  the  number  of  TIP  ports  in  the  PSTN  to  4,  but 
channels  to  the  RL  360  were  frequently  congested. 

The  requirement  for  host  connections  to  the  UCL  TIP  results  fro::; 
a problem  which  has  inhibited  network  use  for  a number  of  groups, 
that  of  input  and  output  with  only  terminal  access.  This  problem 
was  discussed  in  the  users  report  for  1975  (Chapter  7 of  Kirstein, 
1976A) . 

Other  problems  have  arisen  this  year  which  are  peculiar  to  our 
node  and  the  attachment  of  the  PI.  360  to  the  network.  Because 

of  our  slow  link  to  the  rest  of  ARi’ANET  (v;e  have  a 9.6K  bps  Line  to 
Norway  compared  with  50K  bps  lines  over  most  of  tlie  network),  and  the 
growing  congestion  of  the  transmission  links,  there  were  timeout 
problems  with  the  numerous  Tenex  systems  we  use.  This  meant  that  it 
was  very  difficult  for  us  for  a time  to  actually  establish  a bogin 
to  a Tenex.  This  problem  was  solved  by  the  extension  of  t.he  relev- 
ant Tenex  timeout  period,  to  allow  enough  time  for  a response  to  bo 
received  from  the  UCL  node. 

Our  method  of  attaching  the  RL  IBM  360/195  as  a host  to  the 
ARPANET  has  been  to  implement  all  the  ARl’ANET  protocols  in  our  local 
PDP9,  which  simulates  a remote  workstation  to  the  360.  This  has 
worked  very  well,  but  some  disadvantages  have  become  noticeable  this 
year.  One  major  snag  is  that  we  have  to  implement  our  software  in 
terms  of  the  360  operating  system,  over  wliich  we  have  no  direct 
control;  our  ARPANET  File  Transfer  Program  has  to  submit  two  jobs  to 
the  360  to  get  a file  transferred  from  Rutherford  to  a site  in  the 
US.  This  can  take  a few  minutes  or  more,  a frustrating  wait  for  the 
user.  Another  difficulty  is  that  having  to  go  through  the  UCL  PDP9 
to  get  to  the  RL  360  means  that  there  is  twice  the  probability  of  a 
failed  connection;  this  makes  remote  interactive  use  from  the  US 
less  attractive.  Finally,  the  operating  system  at  RL  was  not  designed 
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for  remote  interactive  use  and  it  tins  been  difficult  for  a new  US 
usov  to  find  his  way  round  the  system. 

These  problems  are  all  beiny  tackled.  An  improved  file  transfer 
program  will  soon  be  available  which  should  at  least  make  the  process 
less  frustrating  to  the  user,  by  relaying  messages  on  the  progress  of 
tne  transfer.  Online  documentation  is  being  put  on  the  360  which 
will  help  users  get  more  information  about  the  system,  and  it  is 
hoped  to  improve  Help  facilities  when  time  permits. 

The  effort  is  well  worth  while,  for,  in  spite  of  the  above  diffic- 
ulties, collaborative  research  between  groups  using  the  RL  360  and 
sites  in  the  US  is  proving  very  valuable  to  both  parties.  The  net- 
work provides  a means  of  truly  working  together  which  was  not  in 
any  v/ay  possible  before. 

The  pattern  of  use  as  a whole  from  the  UK  is  analysed  in  Section 
9.2,  and  comparisons  are  made  with  1975.  Details  of  individual 
groups  use  are  given  in  Section  9.3. 

The  information  is  defective  in  two  respects.  First,  the  UCL 
usage  is  not  mentioned;  most  of  the  rest  of  this  report  covers  that 
topic.  Second,  the  information  is  based  on  the  utilisation  of  the 
network  by  the  UK  research  groups  - not  on  direct  feedback  from,  US 
col laborators . The  UK  groups  are  obligated  to  furnish  us  with 
research  and  progress  reports  - thus  making  the  writing  of  this 
chapter  possible.  It  is  impractical  to  obtain  the  same  quality  of 
feedback  from  the  US  collaborators  directly.  Finally,  in  Section 
9 .4  conclusions  are  made  from  experience  so  far  about  the  usefulness 
of  the  UCL  node  to  UK  and  US  research. 

9.2  Analysis  of  Usage  during  1976 

This  report  considers  the  activities  of  34  research  groups  for 
whom  approval  was  received  from  the  Governing  Committee  of  the  UCL 
ARPANLT  project  for  their  use  of  the  ARPANET  node.  It  is  based  on 
their  individual  reports  submitted  to  UCL  at  the  end  of  1976.  A 
number  of  other  groups  were  also  approved,  but  so  late  in  the  year 
that  It  IS  too  soon  to  make  any  assessment  of  their  use. 


Of  the  34  groups  considered,  10  may  be  classified  as  being  'highly- 


active',  12  have  'low-activity'  status,  and  the  remairanq  12  have 
made  virtually  no  use  of  the  network  during  the  year.  This  compares 
with  1975,  when  only  7 groups  out  of  30  v/ere  highly-acti ve  in  their 
use  of  the  network,  although  only  5 groups  were  non-active. 

There  is  no  predominant  reason  why  so  many  groups  have  been 
inactive  this  year.  The  reasons  vary  widely,  and  relate  mostly  t 
the  individual  situation;  some  have  been  held  back  by  lack  of  time 
or  money,  some  by  illness.  A few  have  been  unable  to  get  the  accoun 
they  needed  on  network  machines  - usually  where  they  were  unable  to 
establish  mutually  beneficial  contacts  with  Uf  fell'iw  research  work- 
ers with  ART'A  contracts. 

The  distinction  between  high  and  lov;  activity  on  the  network  is 
not  always  easy  to  make.  It  is  not  a reflection  simply  of  the  amoun 
of  time  spent  accessing  hosts;  it  is  more  an  indication  of  tlie  impor 
tance  of  network  access  to  the  research  group  concerned.  A nuirirer 
of  users  find  network  access  useful  but  could  progress  with  their 
research  without  it;  these  we  classify  as  ' low-activity ' . 'High- 
activity'  groups  arc  doing  work  which  would  either  not  be  possible 
at  all  or  would  progress  much  more  slowly  without  the  network. 

The  resources  available  on  the  ARPA  network  vary  tremendously. 
There  are  therefore  many  different  ways  of  using  the  network,  and  it 
is  interesting  to  compare  these;  this  will  be  done  later  in  this 
seccion.  A number  of  points  can  be  made,  however,  about  network  use 
in  general.  It  does  seem,  for  instance  that  a new  user  should  expec 
that  it  will  take  3-6  months  before  he  can  begin  useful  work.  The 
only  exception  to  this  has  been  database  access,  where  the  instruc- 
tions for  information  retrieval  are  clearly  la  id-out  and  the  system 
has  been  designed  for  easy  use. 

'I'here  are  a number  of  reasons  why  it  takes  longer  to  establish  a 
means  of  using  a computer  on  a network  than  on  a local  machine.  It 
may  take  a v/hile  to  arrange  an  account  on  a remote  machine;  having 
established  an  account,  there  may  be  delays  in  getting  docuirientation 
and  information  on  using  the  system.  Again,  some  machines  connected 
to  ARPANET  have  operating  systems  which  were  not  designed  for  inter- 
active terminal  access  and  are  therefore  difficult  to  use.  Most 
important  of  all,  a pattern  of  use  has  to  be  established,  particular 
if  the  project  is  a collaborative  one;  it  is  very  easy  to  see  that 
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9.2.2  .Mocie  of  Network  Use 

As  mentioned  earlier,  the  ways  in  which  UK  research  groups  use 
the  network  vary  quite  considerably.  There  are  basically  four  types 
of  use  at  present:  Database  access,  use  of  teleconferencing  and  * 

message  facilities  for  the  exchange  of  ideas  and  opinions,  access 
to  software  and/or  data  at  a remote  site,  transfer  of  files  from  a 
remote  site  to  a local  one.  Some  groups  use  only  one  method,  others 
may  use  a combination  of  methods. 

Database  access  is  made  by  the  group  of  users  who  are  participating 
in  the  British  Library  CANCERLINE  Project  and  by  the  Thames  Poly- 
technic Project.  CANCERLINE  is  available  via  the  NLM  machine,  which 
is  not  connected  as  a proper  host  to  the  network  and  is  difficult 
to  access.  This  difficulty  has  been  overcome  by  a program  written 
at  UCL  which  makes  the  connection  for  the  user.  CANCERLINE  itself 
is  a good  system  and  has  been  used  successfully  without  any  further 
problems.  The  Datacomputer , a mass  storage  device,  is  still  largely 
an  experimental  system,  and  requires  considerable  time  to  become 

familiar  with.  Access  to  it  is  therefore  not  typical  of  a database  J 

system;  the  difficulties  involved  are  similar  to  those  of  other  newly-  ! 

developed  special  resources,  such  as  the  ILLIAC  IV  parallel  process-  | 

or.  Resources  of  this  kind  are  so  unique  and  so  new  that  the  intrep-  ! 

id  user  must  tread  slowly  and  carefully  around  the  system  until  he 
identifies  the  hazards. 

Use  of  the  network  for  teleconferencing  and  the  exchange  of  ideas 
is  now  so  well  established  that  there  are  few  problems  involved. 

Members  of  the  UK  Ministry  of  Defence  have  collaborated  with  the  US  ! 

Department  of  Defense  in  the  evaluation  of  the  MoD  real-time  language  I 

CORAL  over  the  network.  Wilkinson  of  the  Medical  Research  Council,  | 

Cambridge,  is  collaborating  with  Donchin  of  Urbana  on  the  analysis 

of  neurophysiological  data,  using  teleconferencing  methods.  There  i 

have  been  no  problems,  except  that  teleconferencing  can  be  somewhat 
tedious  using  a slow  terminal. 

The  most  satisfactory  way  of  using  the  network  from  a terminal  is 
to  access  remote  software  and  data.  This  usually  requires  only  a 

small  amount  of  input,  and  if  the  program  being  run  involves  lengthy  i 

computations,  any  delay  in  response  from  the  net  will  not  matter  too 
much.  Brunei  U and  Cambridge  U Computer  Laboratory  have  used  this 
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method  successfully.  If  the  output  from  the  remote  program  produces 
large  files,  there  is  the  problem  of  getting  it  into  hard  ^opy  form 
without  tying  up  the  terminal  for  hours;  this  problem  has  been  large 
overcome  for  UK  users  by  the  attachment  of  a line-printer  to  the  UCL 
TIP  and  using  this  to  print  user  files. 

The  fourth  way  of  working  is  to  transfer  software  or  data  from,  a 
remote  host  machine  to  a local  one,  and  use  it  there  for  development 
and  testing.  This  method  is  used  for  the  high-energy  physics  coll- 
aboration between  Oxford,  Harvard,  Illinois  and  Chicago,  as  they 
have  encountered  some  frustration  in  using  the  Rb  360/19  5 froiri  the 
US.  The  problem  stems  from  having  to  rely  on  three  computers  all 
being  operational  at  the  same  time  (Illinois,  UCL,  RL) . With  widely 
differing  local  times  at  each  end,  different  maintenance  periods, 
together  with  broken  or  aborted  connections,  it  can  be  difficult  at 
times  to  achieve  a useful  work  session.  This  situation  has  been 
reported  by  only  one  group,  however,  and  should  not  be  taken  as  a 
typical  network  situation.  If  the  only  viable  way  to  use  the  networ 
was  to  transfer  files  from  one  site  to  another,  then  it  would  be 
difficult  to  justify  its  existence  in  terms  of  resource-sharing. 

Flexibility  would  appear  to  be  the  keyword  for  successful  ex- 
ploitation of  the  network's  facilities.  Most  projects  develop  bi- 
stages,  and  each  stage  may  need  a different  approach  or  a different 
type  of  resource.  It  is  interesting  to  see  how  two  of  our  user 
groups,  Bristol  U and  Durham  U,  have  used  the  network  this  year. 
Bristol  began  by  transferring  programs  written  originally  on  the 
CDC  7600  at  LBL  onto  the  RL  360/195,  where  further  development  took 
place.  They  are  now  entering  a second  stage  of  work.  For  technical 
reasons  the  next  stage  in  the  program  is  best  run  at  LBL,  where  the 
facilities  are  better  for  their  purpose.  They  are  currently  devel- 
oping the  programs  to  output  the  analysis  from  the  360  into  a form 
for  transferring  to  LBL  for  further  analysis.  At  the  same  time, 
Kelly  of  LBL  scans  the  results  of  the  360  runs  from  LBL  and  keeps 
a log  of  the  status  of  the  runs. 

Working  in  a similar  way,  Durham  U have  implemented  a version  of 
the  LBL  Data  Management  Program,  BKYBDMS,  on  the  RI,  machine.  During 
implementation  it  was  invaluable  to  be  able  to  test  the  machine 
independence  of  their  IBM  subroutines  by  running  them  on  the  LBL  CDC 
machine.  A second  stage  of  the  work  has  involved  the  design  of 
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a oodiny  ianyuacjo.  This  has  been  set  up  at  LBL  to  enable  otliers 
in  the  collaborative  yroup  to  add  data  and  carry  out  experiments. 
Future  use  of  the  net  for  Durham  U will  involve  the  querying  of  the 
databases  at  LBL  for  book-keeping  purposes. 

Another  group  whose  use  has  developed  interestingly  this  year 
is  the  Blacknest  Research  Centre.  They  began  in  quite  a modest 
way  by  accessing  seismic  data  files  at  ISI.  Now  they  have  set  up 
their  own  seismic  database  on  the  RL  360/195  and  regularly  exchange 
data  with  seismic  centres  in  the  US.  For  them,  file  transfer  is  the 
ideal  way  of  working,  since  the  files  are  small  and  the  data  is 
needed  locally. 

A final  point  needs  to  be  made  about  the  use  of  special  resources 
such  as  the  ILLIAC  IV  parallel  processor.  This  is  such  an  expen- 
sive resource  that  compilation  and  debugging  of  software  to  be  run 
on  it  must  be  carried  out  on  another  host  machine  and  then  transferred 
to  the  ILLIAC  for  execution.  This  type  of  work  can  be  carried  out 
from  a terminal  on  a small  scale,  but  any  large-scale  development  of 
programs  really  needs  to  be  done  via  a local  host,  so  that  listings 
and  dumps  can  be  obtained  for  examination.  This,  of  course,  will 
tend  to  apply  to  software  development  on  any  remote  machine,  but  is 
especially  true  of  a specialised  resource  whore  so  many  problems  are 
likely  to  occur  before  the  user  comes  to  grips  with  it. 

In  summary,  full  use  of  ARPANET  is  best  achieved  through  a local 
host  rather  than  bv  terminal  access.  A flexible  approach  to  the  way 
in  which  one  works  will  enable  the  resources  and  facilities  the 
network  has  to  offer  to  be  exploited  most  fully. 

9.2.3  Problems  Encountered  in  the  Use  of  ARPANET 

Most  of  the  problems  encountered  by  UK  users  iiave  already  been 
mentioned.  Four  groups  had  some  trouble  in  accessing  and  making  use 
of  two  hosts,  the  NLM  machine  and  the  ILLIAC  TV.  US  users  have  also 
found  the  operating  system  of  the  RL  360  difficult  to  use.  The  lesson 
to  be  learned  from  these  experiences  must  surely  be  that  when  the 
decision  is  taken  to  connect  a machine  to  a network,  adequate  consid- 
eration must  be  given  to  providing  Help  facilities  and  suitable  user 
interfaces  to  the  system. 
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Several  groups  found  their  work  severely  hampered  by  the  lack  of  ! 

an  account  on  a suitable  US  machine.  Use  of  a guest  account  can 
usually  be  arranged  for  short  term  experimental  work:  for  serious 
use,  a UK  user  needs  to  establish  collaborative  links  with  fellov; 
research  workers  in  the  US  - preferably  before  he  contemplates  using 
the  network. 

I 

The  inability  to  cope  with  large  I/O  files  from  a terminal  impeded  1 

full  collaboration  for  two  groups.  Queen  Mary  College  and  Canibridge  i 

U Computer  Laboratory.  This  problem  should  be  solved  when  EPSS  is 
in  full  operation  (see  Chapter  6) . i 

i 

The  only  other  problem  of  note  was  the  slowness  of  response  from 
the  net.  This  is  not  so  apparent  early  in  the  UK  day,  but  becomes 
a nuisance  by  early  afternoon,  when  US  workers  start  to  use  the 
machines.  ^ 

On  the  whole,  most  users  found  the  network  reliable  and  most  of 
the  hosts  easy  to  use. 

9.2.4  Mode  of  .ziccess  to  the  Network 

( 

Out  of  the  20  users  actively  using  the  net  this  year,  15  did  so 
from  terminals,  4 via  the  Rutherford  Laboratory  and  1 group  has  a 
leased  line  connection  to  tlie  UCL  TIP.  Of  the  15  terminal  users,  6 
groups  admitted  to  finding  this  type  of  access  unsatisfactory,  because 
It  was  slow  and  inhibited  input  and  output.  Even  for  fast  terminals, 

I/O  is  restricted  by  very  limited  buffer  space  in  the  TIP.  The  only 
type  of  ARPANET  user  for  which  terminals  seem  perfectly  adequate  is 
for  database  access  or  for  running  programs  when  I/O  is  minimal. 

There  is  also  a problem  of  poor  quality  transference  of  data  over 
long  distances  via  the  public  switched  telephone  network.  This  may 
distort  I/O  to  a degree  where  work  becomes  very  difficult. 

9.2.5  Connection  Times 

The  Medline  group  used  most  connection  time  through  the  UCL  TIP, 
since  there  are  about  15  participating  groups  and  they  carried  out 
searches  on  a daily  basis.  Apart  from  this,  most  users  were  able 
to  carry  out  their  work  quickly.  The  group  reporting  the  longest 
average  weekly  connection  time  was  Salford  U,  with  6 hours  a week. 
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On  the  other  liand,  Bristol  U used  only  a few  minutes  a week  in  the 
early  stages  of  their  project  and  expect  to  be  spending  no  more  than 
30  minutes  a week  in  the  next  stage  of  tlieir  collaboration.  Th.e 
average  connection  time  for  highly  active  users  is  around  2 hours  a 
week . 

9.2.6  Summary 

Use  of  the  network  this  year  has  been  muc!\  more  interesting  to 
analyse,  because  ttie  patterns  of  use  have  become  much  clearer.  Ivith 
the  o^nnectitDu  of  iiiiportant  1 aboratc;r ics  such  as  the  Lviv;rencc  Berkele 
and  Argonne,  important  col  lab.'.rativc.'  work  has  rk  veloped  for  which 
the  o.xi.stence  of  the  network  is  absolutely  vital.  UK  users  working 
col labora t ively  witli  US  groups  liave  increased  tlieir  use,  wJiilst 
others  have  tended  to  decline.  The  niain  exception  to  this  are  the 
two  groups  using  the  II.LIAC  IV,  who  iiave  spent  a l-uig  time  getting 
over  the  experimental  stafje  of  using  this  advanced  maciiine  and  are 
just  beginning  serious  work. 

Use  has  been  made  of  17  (out  of  4 1)  ARI’ANUT  Server  hosts,  most  af 
wtiich  proved  easy  to  use,  with  help  facilities  and  message  systems. 

No  UK  user  has  stopper]  using  tlie  network  because  h.e  found  it  too 
difficult . 


9.3  UK  Research  Projects  usin<i  ARPANKT 

This  section  dt-scrilies  the  ways  in  v/hich  the  numerous  UK  research 
groups  who  have  liad  approval  during  1 976  have  used  the  netv/ork  to  aid 
their  woik.  They  are  subdivided  into  high  and  low  activity  groupings 
in  terms  of  the  extent  of  their  use  of  the  network. 

On  the  whole,  the  high-activity  section  consist. s of  groups  wtio 
are  well-established  ARPANKT  users;  they  have  ijot  over  tiic  experim- 
ental stage,  iiave  tlie  software  and  accounts  that  they  nectl  and  tlie 
confidence  to  use  them  over  the  network.  Tiio  Blackncst  Research 
Lstabl  ishment  , Uuih.im,  Bristol,  B.ilford  and  Reading  Universities,  all 
come  into  this  cateejory.  Oxford  University  Nuclear  Physics  group 
iiave  also  continued  their  collaboration  with  Chicago,  Harvard  and 
Illinois,  begun  in  1979.  The  British  Library  Research  and  Develop- 
ment Division  have  continuetl  tiieir  experimental  information  retrieval 
project,  using  the  CANCKRLINK  system  this  year  instead  of  MEDLINE. 
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Two  other  groups,  Culhani  LuDoratory  and  the  Royal  Signals  and 
Radar  Establishment,  have  been  active  in  another  sense.  They  have 
been  working  hard  to  establish  their  own  machines  as  hosts  on  the 
network,  for  the  purpose  of  collaborating  with  specific  groups  in 
the  US.  These  will  be  described  first. 

9.3.1  High-Activity  Projects 

Royal  Signals  and  Radar  Establishment  (RSRE ) 

The  RSRE  at  Malvern  h.^s  a GEC  4080  computer  which  run<~  the  real- 
time language  CORAL.  The  latter  is  being  evaluated  by  the  US  Depart- 
ment of  Defense  as  part  of  their  project  to  examine  various  real-  I 

i 

time  languages  in  terms  of  military  requirements.  In  order  to  i 

facilitate  this  evaluation,  the  RSRE  machine  has  been  connected  as  | 

a host  to  the  ARPA  network  via  one  of  the  UCL  PDP9s  (see  Section  2.5) . i 

This  connection  was  particularly  useful  during  March,  when  a group  | 

fro. I.  RSRE  visited  the  US  DoD  to  give  an  instruction  course  on  CORAL;  | 

the  use  has  continued,  however,  during  the  rest  of  the  year. 

j 

j 

Culham  Laboratory  | 

The  Culham  fusion  laboratory  lias  joint  interests  with  US  laborat- 
ories in  the  same  field  and  work  iias  been  going  on  this  year  to  dev-  j 

elop  software  to  allow  the  Culham  ICL  system  4/'72  to  be  connected  as  ; 

a host  to  ARPANET  in  order  to  facilitate  UK/US  collaboration  (see 
Section  2.7).  : 

Blacknest  Research  Establishment  j 

I 

The  Blacknest  Research  Establishment's  project  to  exchange  seismic 
data  with  centres  in  the  US  via  ARPANET  began  in  quite  a modest  way 
in  1973,  when  the  ARPANET  link  was  first  established  at  UCL.  They 
began  by  accessing  data  from  the  Seismic  Data  Array  Center  (SDAC) , 
Washington  and  then  began  to  set  ujj  tlieir  own  database  on  the  RL  360 
195  for  access  for  US  counterparts  (Blarney , 1 9 76  ).  This  data  is 
now  being  accessed  by  the  Vela  Seismolog ica 1 Center,  SDAC,  and  soon 
the  National  Earthquake  Information  Service  (NEIS). 

The  latter  is  the  foremost  collector  of  eartliquako  data  from 
diverse  sources.  Computers  and  computer  networks  are  opening  many 
opportunities  for  improving  the  quality  of  data  which  NEIS  collects. 
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and  by  participatincj  in  the  transmission  of  data  by  computer  networks,  j 

Blacknest  is  assistinq  in  a project  tiiat  will  permit  near-real  time  j 

location  of  important  earthquakes.  j 

i 

KblS  have  always  received  data  from  Blacknest,  but  rather  indirect- 
ly. By  transmitting  data  via  ARPANET,  it  may  be  obtained  far  m.ore 
quickly  than  before.  The  current  data  files  on  the  360  are  in  a 
different  format  from  tiiat  used  by  NEIS,  so  Blacknest  are  implemen- 
ting software  whicli  wii  1 reformat  tlie  data  in  tlie  standard  NEIS 
format,  before  sending  it  to  the  PDI’-IO  at  the  Information  Sciences 
Institute,  California  (ISI). 

For  tlieir  part,  Blacknest  liave  been  receiving  NORSAR  bulletins 
from  the  Norwegian  Seismic  array.  Unfortunately  these  stopped  being 
produced  at  the  end  of  September  due  to  cuts  in  the  Norsar  research 
budget.  Blacknest  are  also  now  receiving  daily  bulletins  from  a 
station  in  Ottawa.  These  are  received  via  the  Vela  Center,  who 
make  the  data  available  in  files  on  the  ISI  machine.  In  due  course, 
wiien  NEIS  is  fully  integrated  'with  ARPANET,  they  hoj-ie  to  got  much 
more  quickly  the  seismic  epicentre  location  data  which  they  current- 
ly receive  via  air  mail.  Blacknest  claim  that  their  attachment  to 
ARi’ANET  greatly  aids  their  researcii. 

Bristol  University 

Aicock  (jf  the  Physics  lje|.>a  r t.ment  , Bristol,  has  been  using  ARPPvNET 
via  the  RE  360/195  to  collaliorate  with  Kelly  at  tlie  Lawrence  Berkeley 
Laboratory,  California  (LBL) . They  are  engaged  on  a joint  project  to 
analyse  pion-pion  to  nucleon-antinucleon  scattering  data.  Use  of  the 
ARPANET  has  enabled  them  to  establish  programs  written  originally  on 
the  CDC  7600  at  LBL  onto  the  360,  where  further  development  has 
taken  place.  Total  connect  time  for  this  was  only  a few  minutes  per 
week  on  average. 

They  are  now  entcrimi  a second  stage  of  work.  For  technical 
reasons  the  next,  stage  in  the  program  is  best  run  at  LBL  where  the 
facilities  are  ijetter.  'I'hey  are  currently  developing  the  program  to 
output  tlie  ^ina  lysis  from  the  360  into  a form  for  transferring  to  LBL 
for  further  analysis.  Tins  part  of  the  work  could  not  be  contemplated 
without  the  network  and  tlie  ability  to  transfer  files.  It  is  also 
immensely  useful  for  Kelly  to  scan  the  results  of  the  360  runs  from 
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LBL  and  to  keep  up-to-date  loq  sheets  on  the  status  of  the  runs. 
British  Library  Research  and  Development  Division 

The  experimental  project  to  access  databases  and  the  information 
retrieval  system  at  the  US  National  Library  of  Medicine  has  contin- 
ued this  year, with  the  modification  that  the  database  used  has  been 
CANCERLINE  instead  of  MEDLINE.  Comparisons  of  the  two  databases 
have  been  made  by  the  user  centres  participating  in  the  experiment. 
These  user  centres  must  record  details  of  their  searches  for  BL 
records  in  return  for  terminal  access  to  the  information  retrieval 
system.  Their  pattern  of  usage  of  the  database  has  been  measured 
also  by  the  UCL  group  to  corroborate  the  data  furnished  by  the  user 
centres.  These  measurements  have  been  discussed  in  Chapter  8. 

Cambridge  University  Computer  Laboratory 

Fitch  has  been  engaged  since  1973  in  a collaborative  project  over 
ARPANET  with  Hearn  of  Utah  U.  This  work  has  been  concerned  with 
the  comparison  of  algebra  systems,  CAM/iL  and  REDUCE,  produced  resuec 
tively  at  Cambridge  U and  Utah  U.  Independent  com.parisons  of  eacii 
other's  systems  have  led  to  substantial  improvements  in  algorithms 
and  the  development  of  new  solution  techniques.  This  project  was 
essentially  completed  by  the  end  of  1975. 

Work  has  begun  on  a new  project;  Fitch  has  taken  a copy  of  the 
second  version  of  the  LISP  compiler  over  tlie  net  and  is  currently 
using  it.  This  cooperation  does  not  require  much  machine  time  on 
the  A.RPANET , but  relies  heavily  on  file  transfer  facilities.  It  is 
hooed  that  EP.SS  will  make  two-way  file  transfer  much  easier. 

They  have  continued  to  use  MACSYMA  as  a help  in  their  algebra 
research.  On  a number  of  occasions  they  have  been  able  to  use  this 
unique  resource  to  considerably  shorten  the  development  time  of  nev; 
algorithms.  Of  particular  note  here  is  the  lielp  they  afforded 
Jackson  (Jackson, 1975) . A package  for  Petrov  classification  was 
implemented  on  MAC.SYMA,  and  as  a result  file  space  was  made  availabl 
to  their  group  on  MIT-MC. 


Durham  University 
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Gault  of  the  Physics  Department,  Durham  U,  heads  the  UK  section 
of  the  International  Particle  Data  Group.  His  work  is  concerned 
with  the  development  of  high  energy  elementary  particle-scatterir.o 
databases . 

During  the  past  year  they  liave  continued  their  collaboration  with 
the  Particle  Data  Group  at  the  Lawrence  Berkeley  Laboratory.  The 
purpose  of  the  work  has  b€?en  in  part  to  implement  an  IBM  version  of 
the  Berkeley  Data  Management  Program,  BKYBDMS , on  the  RL  360/195. 
This  aspect  of  the  work  started  in  Marcli  1 976  and  a first  version 
1.0  was  running  in  July.  An  improved  version  was  implemented  in 
October . 

BKYBDMS  is  a comple.x  pi.'o'iram  v^ritten  on  .a  CDC  machine  and  during 
the  implementation  poriotls  it  v.'as  invaluable  to  be  able  to  test  t.he 
machine  independence  of  their  IBM  subroutines  by  nanning  them  on 
the  Berkeley  CDC  machine.  Also  the  ability  to  run  BDMS  at  Berkeley 
from  Durham  was  i rival  ual)le. 

Another  aspect  of  the  work  has  involved  the  design  of  a data 
encoding  language,  PPDL  (Particle  Pliysics  Data  L.inguagc).  The 
design  is  being  carried  out  at.  Durliam.,  LBL  and  Cal.  Tech.  /As  Cal. 
Tech,  has  ARPANHT  .iccess  tliroucih  its  LBL  workstation,  they  have  been 
able  to  compare  codincj  languages  directly  by  setting  them  up  on  the 
most  convenient  machine  .uid  allowing  tlie  others  in  tiie  group  to  add 
data  and  experiment  witii  them. 

They  have  not  yet  got  to  ttie  st acre  of  regular  data  transfer  bet- 
v.’oen  the  two  groups  using  ARPANHT,  .ind  it  is  not  obvious  tiiat  tliey 
will;  however  a major  future  use  of  /ARP/\NLT  will  bo  the  querying  of 
the  databases  at  LBL  for  t ire  i i'  ov/n  book-keeping  purposes  rather  than 
the  transfer  of  /lata.  Thc'  actual  dat  i v/ill  most  likely  be  exchanged 
by  tape  at.  recjular  intervals. 

Gault  summarises  his  ARI’ANKT  activities  by  s, tying  that  the 
net'./ork  has  pl.iyed  i s i<m  i f i cant  and  u.seful  role  in  their  work,  and 


that  without  it  the  nature  of  their  project  would  be  altered  consid- 
erably. 

Oxford  University 

Quirk  of  the  Department  of  Nuclear  Phy‘'ics,  Oxford,  leads  a 
group  who  are  working  in  collaboration  with  groups  at  Harvard, 

Chicago  and  Illinois.  This  work  concerns  experiment  398  at  the 
Fermi  National  Accelerator  Laboratory,  Illinois.  Muon-scatter  i nc; 
data  gathered  at  Fermi  is  reduced  and  analysed  using  software  imp- 
lemented on  the  RL  360/195. 

The  collaboration  has  been  working  successfully  for  several  years 
(Anderson, 1976) . The  main  difficulty  is  that  use  of  the  RL  360 
from  a host  site  in  the  US  depends  on  three  computers  (the  US  machine, 
the  UCL  PDP9 , and  the  RL  360)  being  operational  at  widely  different 
local  times  and  maintenance  periods.  This , together  with  broken  or 
aborted  network  connections  has  caused  the  groups  to  use  tb.e  network 
for  swapping  data  and  programs  rather  than  attempting  to  remotely 
control  the  data  processing  or  detugging  of  programs.  The  character- 
istics of  the  UCL  node  (described  earlier  in  Section  9.1)  have  thus 
affected  the  way  in  which  the  network  has  been  used  by  these  collab- 
orating groups.  Local  difficulties  at  Harvard  and  Chicago  have  also 
caused  some  problems;  there  has  often  not  been  a suitable  printer 
available  at  the  time  of  transfer  of  line  printer  output  files. 

Nevertheless,  work  is  proceeding  satisfactorily  and  close  contact 
is  kept  between  members  of  the  UCL  research  group  and  Illinois  t' 
smooth  out  any  problems  that  occur  with  transferring  files. 

Reading  University 

Hockney's  group  in  the  Computer  Science  Dept,  Reading  U,  is 
engaged  in  a project  to  evaluate  and  develop  rapid  elliptical  solvers 
and  particle/mesh  algorithms  for  parallel  architecture  computers. 

The  project  involves  the  study  of  different  parallel  architectures, 
in  addition  to  the  numerical  algorithms. 
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They  have  established  an  association  with  Lomax  and  Stevens  at 
NASA  Ames,  Moffet  Field.  A col laborat i ve  pro3ect  has  been  arranged 
and  they  hope  to  transfer  their  P^M  algorithm  to  the  ILLI.AC  IV  for 
use  in  vorte.x  calculations.  In  return  for  this  they  have  an  account 
number  and  file  space  on  the  ILLIAC  IV  (Jesshope,  1976 ) and  on  th.e 
•Ames  IBM  360  TSS  system.  The  latter  is  used  for  com.pilation  and 
checkout  of  the  CFD  code  (a  Fortran-based  parallel  language)  before 
submission  to  the  ILLIAC  IV. 

Preliminary  results  using  the  ILLIAC  IV  have  been  disappointing 
in  terms  of  the  computing  pov/er  available;  its  performance  on 
benchmark  tests  was  only  twice  that  of  a 360/195  rather  than  ten 
times  (as  expected).  The  great  difference  betv/eon  estimated  run 
time  and  measured  run  time  is  due  to  the  restrictions  im.poscd  by 
non-overlap  mode  proces.sinn.  In  spite  of  this,  use  of  ILLI.^C  IV 
continues  to  l:>e  invaluable  to  this  project  since  no  other  parallel 
computer  is  accessible. 

Salford  University 

A project  to  develop  and  verify  algorithms  for  predicting  steady 
supersonic  flow  fields  is  headed  by  Walkdcn  of  the  department  of 
Mathematics  at  Salford  I'.  Such  alaorithms  involve  very  complex 
multi-dimensional  matrix  calculations  that  are  ir.piract ical  for 
ordinary  serial  processing;  for  this  reason,  th.e  ILLI.VC  IV  parallel 
processor  machine  is  being  u;;eil  ti)  develop  programs. 

Programs  are  w'-i*ten  in  CFO  and  comp'»i  led  and  debugged  on  the  RL 
360/'195  machine.  Only  when  they  are  ready  to  be  run  arc  the  program 
files  tr  insferretl  to  ttu'  Tetu.'x  interfacing  the  ILLIAC  IV  (I4-Tenex)  . 
'.'ntil  February  1976,  l.ick  of  an  14-TeiAex  file  transfer  facility 
meant  several  d<iys  df.'l.iy  when  a file  had  to  be  transferred  between 
14-Tenex  and  F^I..  The  introduction  of  this  facility  at  that  time  has 
enabled  file  transfers  to  be  initiated  by  the  user,  and  this  has 
been  extremely  useful.  Some  difficulties  with  file  transfers  have 
been  exper  i I’ncod ; t hi'  main  difficulty  is  the  lenuth  of  time  taken 
to  transfi'r  files  from  the  hea  v i 1 y- 1 oaded  360  via  t lu'  slow  nCL  link 
to  AFd'AN’LT. 
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The  work  carried  out  so  far  at  I4-Tenex  has  consisted  of  small- 
scale  tests  of  simple  computatioral  procedures.  The  file  space 
allocation  of  100  Tenex  pages  has  been  insufficient  bo  allow  more 
than  one  job  to  be  processed  at  any  one  time,  since  the  ILLIAC 
system  produces  large  output  files  during  processing  and  halts  a 
job  if  insufficient  disk  space  is  available.  It  is  expected  that 
more  file  space  will  be  made  available  soon  to  ease  this  situation. 

Progress  has  been  made  towards  achieving  their  short  term  aim  of 
obtaining  run  times  for  the  calculation  of  solutions  of  partial 
differential  equations  associated  with  fluid  flow  field  problems. 

The  experience  gained  through  performing  rather  simple  tests  has 
also  suggested  programming  strategies  for  more  complicated  problems 
(Walkden , 1975 ) . 

The  next  stage  of  the  work  is  to  test  a full  supersonic  flow 
calculation  program,  followed  by  full  scale  tests  of  algorithms  and 
computer  strategies  involving  the  complete  I4-Tonex  system.  This 
will  begin  in  1977. 

9.3.2  Low-Activity  Projects 

British  Library  Lending  Division 

Harley  of  the  British  Library  Lending  Division  (BLLD)  has  been 
leading  a project  to  investigate  the  feasibility  of  an  inter-library 
loan  network  between  the  British  Library  and  the  National  Library 
of  Medicine  (NLM) . The  purpose  of  the  experiments  has  been  to  dev- 
elop and  test  a system  DOCLINE  whicli  minimises  input  and  reporting 
costs  and  uses  a central  computer  (NLM)  for  routing,  reformatting 
and  address  file  maintenance. 

DOCLINE  is  now  operating  satisfactorily  and  all  the  16  regional 
medical  libraries  in  the  USA  are  now  able  to  channel  their  photo- 
copy requests  to  the  NLM  computer.  Requests  which  cannot  be  ser- 
viced by  NLM  are  transferred  to  the  BLLD  file,  from  which  they  are 
retrieved  daily  by  BLLD  staff.  7931  requests  were  retrieved  in  the 
12  months  ending  June  1976,  and  5668  iirins  were  supplied.  Reports 
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of  items  supplied,  and  reasons  for  non  supply  of  others,  are  enter- 
ed from  the  BLLD  terminal  daily. 

~rri-though  the  system  works  well,  and  use  of  ARPANET  was  invaluable 
in  getting  it  established,  access  to  it  through  ARPANET  has  been 
terminated.  By  mutual  agreement  tlie  system  is  now  operated  via 
TYMNET,  since  it  has  become  a routine  operation. 

Brunei  University 


The  Decision  Analysis  Unit  at.  the  Institute  of  Organisation  and 
Social  Studies,  Brunei,  is  participating  in  a decision  analysis 
project  with  five  other  groups  from  the  UK  and  US. 

The  six  groups  have  accc'unts  at  ISI,  these  accounts  liaving  been 
established  in  order  to  facilitate  tlio  sharing  of  computer  soft- 
ware and  the  exchange  of  ideas;  Brunei's  part  of  the  project  has 
been  to  develop  CALIBA  to  determine  an  individual's  accuracy  in 
assessing  probabilities  (Whalley,  197h)- 

The  project  has  progressed  vvel  L , but  considerable  difficulty  has 
been  experienced  with  local  telephone  linos;  extr  inoous  'noise' 
on  the  lines  has  c.iused  t r ansm  i :;s  i on  errors  during  input.  Apart 
from  this,  Brunei  ' use  'if  t in'*  network  has  betui  very  successful  and 
they  have  been  impiressed  by  the  reliability  and  speed  of  the  Tencx 
system  at  TSI . 

Departm.ont  of  Industry 

Pinkerton,  of  the  Tec'hnology  Report  Centre,  has  been  accessing 
the  MEDLINE  sy.stc'm  at  NLM  in  order  to  investigate  developments  in 
informati'in  rctriovil  :;oftv;ar('  and  database;;  in  UP  as  compared  with 
those  in  P,rit.iin  and  Luropt'.  Comparisons  have  been  made  between 
MEDLINE  and  a similar  system  RADAB  on  an  ICL  190D  computer  at  the 
Department  of  the  Environment,  Hastings.  Apparently  MEDLINE  access 
has  some  adv.intages  over  ItADAB;  lioweva''r  snnie  MEDLINE  symbols  are 
not  easy  to  un<Jer:;t.ind , while  RADAFt  uses  full  Enulish  terms  or 
abbreviations  of  tlier.o.  RADAB  lias  been  found  to  be  more  satisfac- 


tory,  and  in  the  second  half  of  1976  tie  Dol  terminal  has  been  used 
almost  continuously  for  R.^DAB  searches. 

Edinburgh  University 

A new  proof-generat ion  system  for  LCF  has  been  designed  and 
implemented  at  Edinburgh  in  the  department  of  Computer  Science.  The 
system  is  implemented  in  UCI-LISP.  A new  version  of  this  is  main- 
tained at  Stanford,  and  Gordon  has  been  investigating  the  Stanford 
version  in  conjunction  with  the  Edinburgii  implementation. 

Medical  Research  Council 


It  has  been  proposed  by  Donchin  of  tiie  U of  Illinois  that  a test 
be  made  of  the  feasibility  of  making  his  laboratory  equipm.ent  avail- 
able for  use  by  remotely  located  investigators  '''ia  the  facilities 
of  .^RPANET.  Wilkinson  of  the  Applied  Psychology  Unit,  MRC , Cambridge, 
is  collaborating  v.’ith  him  on  this  basis.  Use  so  far  of  the  network 
has  been  restricted  by  lack  of  a terminal  at  Cambridge  and  has  been 
confined  to  the  exchange  of  comments  on  graphs  of  statistical  anal- 
ysis of  data.  The  overall  aim  is  for  Wilkinson  to  view  and  analyse 
data  over  the  network.  ^le  envisages  a series  of  studies  in  the 
general  area  of  the  relationship  betw'een  event  related  potentials 
in  the  EEG  and  performance. 

Ministry  of  Defence  (MoD) 

Curry  of  the  MoD  has  been  using  the  network  for  col laboration 
with  the  US  Department  of  Defense  on  the  High  Order  Language  project 
currently  in  progress.  The  network,  facilities  have  proved  useful 
in  coordinating  this  project,  and  in  providing  access  from  the  US 
to  the  MoD  language  CORAL. 

North  London  Polytechnic 

Survey  analysis  packages  are  the  subject  of  an  investigation  by 
Rowe  of  the  London  Polytechnic  Computer  Unit.  He  assigned  a student 
to  the  project,  allotting  him  only  ten  weeks  for  the  task,  even 


though  he  had  no  p^  ior  knowledge  of  the  nctv/ork , or  US  contacts. 

This  was  far  too  siiort  to  make  any  real  progres:. , .md  tiie  exorcise 
was  useful  only  in  issessinq  the  problems  and  experiences  of  a 
naive  nctv/ork  user  (Urinkwater,  1976). 

Numerical  Algorithms  Group,  Oxford 

The  Numerical  ALC]t)rithms  grc^up,  of  Oxford  Computing  Laboratory, 
are  collaborat i n<]  with  a croup  from  the  Computational  Mathematics 
Division,  /^r<Jonne  National  Lal)oratory  (ANL)  . Their  research  inves- 
tigations are  seeking  to  explore  the  role  of  computer  networking 
in  the  development  of  numerical  software,  and  to  establish  the 
problems  of  remotely  installing  and  maintaining  a numerical  softv/are 
library.  Use  of  the  network  so  far  has  been  largely  experim.ental  , 
while  they  assess  tht>  best  way  to  proceed  with  the  project.  Also, 
the  necessary  software  for  file  transfer  has  become  available  at 
ANL  only  recently. 

Queen  Mary  College  (CMC) 

The  Computing  Laberatory  cit  QMC , under  Coulouris,  is  engaaed  in 
research  aimed  at  developing  software  and  system  c'.'^ccpts  to 
enable  lov/-cost  information  processing  systems  t''  be  more  effcctivel 
applied.  The  most  important  goals  are  the  development  of  hiqhly- 
responsivo  interactive  systems,  and  the  position  f effective  a.nd 
generalised  communication  and  cooperation  between  distributed  sys- 
tems. Use  of  the  ARPANLT  enables  them,  to  obtain  information  about 
research  related  to  thc;irs  in  the  U.S.  This  may  be  in  the  form,  of 
online  text  unavailable  in  printed  form  or  in  the  use  of  systems 
developed  as  research  projects. 

They  iiave  been  prevented  from  full  two-way  collaboration  by  not 
tiaving  their  softw.ire  files  on  a UK  host;  they  can  receive  files 
from  the  UK  on  their  PDIMI,  hut  they  are  unable  to  send  files  back 
via  the  UCL  TIP  because  of  limited  TIP  buffer  space.  It  is  hoped 
this  problem  will  be  alleviated  by  the  use  of  the  EPSS  development 
of  Chapter  6. 
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This  year,  QMC  have  supplied  software  to  a number  of  liS  users. 

This  has  been  facilitated  by  ARPANET,  .-nainly  be  providing  minor 
updates  through  normal  terminal  use. 

Royal  College  of  Art  (RCA) 

During  the  last  year  the  primary  use  of  ARPANET  by  the  Department 
of  Design  Research  at  RCA  has  been  for  maintaining  contact  with  US 
research  and  running  programs  of  interest.  The  areas  of  interest 
are  in  architecture  and  design  research,  interactive  graphics,  and 
artificial  intelligence.  The  host  machines  used  wore  CMU-lOA,  Sur.ex- 
Aim,  Mit-Multics,  HARV-10  and  Office-1. 

The  heaviest  use  was  at  CMU-lCA,  involving  the  BDS  system  under 
development  by  Eastman.  It  has  not  been  possible  to  implement  this 
system  in  the  UK,  so  this  use  has  been  a valuable  experience. 

Thames  Polytechnic 

Crowe  and  Avison  of  the  Systems  Analysis  Division,  Thames  Poly- 
technic, are  researching  into  the  implementation  of  relational  data- 
bases. They  have  obtained  an  account  on  the  Unix  system  at  RAND-ISD 
and  are  using  the  INGRES  relational  database  there  to  study  the 
implementation  of  logical  data  structures.  This  will  enable  them  to 
gain  i w.e  insight  into  the  problems  of  a practical  implementation 
of  relational  theory.  They  also  have  the  use  of  a guest  account  on 
the  Datacomputer , on  which  they  are  doing  similar  work  for  the  pur- 
pose of  comparison  with  INGRES. 

University  College  London,  Communications  Studies  Group  (CSG) 

"Technology  assessment  of  the  interaction  between  travel  and 
telecommunications"  is  the  collaborative  project  being  carried  out 
by  the  CSG,  the  Stanford  Research  Institute  and  Bell  Canada.  All 
have  access  to  the  Office-1  machine,  on  which  a common  bibliography 
is  being  developed.  Pye  of  the  CSG  uses  the  network  for  developing 
and  accessing  bibliographies  on  communication  and  telecommainicat ion . 


9.4  Conclusitms 
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Therc  can  be  no  doubt  that  t'.ic  existence  of  the  UCL  link  to 
ARPA."4ET  is  now  invaluable  to  many  of  our  UK  users.  This  point  h.as 
been  made  clear  in  .Sections  9.2  and  9.3.  Some  of  the  projects 
involved  are  important  not  only  to  the  cjroups  concerned  but  also  to 
the  world  of  research  yenerally.  This  is  not  an  overstatement;  for 
example,  the  Oxford/lIarvard/Chicaqo/lil inoi s hiqh-energy  collabor- 
ation is  concerned  with  the  world-wide  search  for  the  basic  struc- 
ture of  matter.  Again,  tdic  oxchaiuie  on  a da  ‘ y liasis  of  seismic 
data  between  Blackr.est  ami  tiie  US,  which  previously  may  have  taken 
v/eeks , enables  immediate  detection  of  seism'^c  disturbance. 

Although  slightly  fevier  groups  tiian  in  1975  were  actively  using 
the  network,  the  v/ork  being  done  v;as  more  constructive.  More  use 
v;as  made  of  the  file  transfer  facility,  without  v.’hich  many  of  our 
users  could  not  have  proceeded.  The  availability  of  tlie  Post  Office 
EPSS  in  1 977  will  enable  more  users  to  work  in  a mode  vinere  they 
can  exchange  files  with  US  sites.  The  availability  of  the  file 
transfer  facility  lias  been  essential  to  almost  all  the  applications 
which  have  made  re.ally  siejnificant  progress. 


10.1  Introduction 


The  present  message  and  text  manipulation  services  offered  over 
ARPANET  are  extremely  important  for  processing  textual  data  input 
directly  into  one  of  the  hosts  on  the  network.  However,  we  have 
long  felt  that  these  services  have  one  element  missing;  there  are 
no  facilities  to  deal  with  material  which  does  not  originate  in 
machine  readable  form,  and  the  facilities  for  processing  non-  textual 
material  are  poor. 

We  are  investigating  the  input  of  documents,  their  transmission, 
their  storage  and  subsequent  retrieval,  their  manipulation  in 
conjunction  with  other  files,  and  their  final  output  on  devices 
different  from  those  on  which  they  were  input. 

This  work  is  not  a purely  theoretical  exercise.  As  reported  in 
(Kirstein, 1976A) , during  Stage  1 (1975-1976)  specific  experiments 

were  undertaken  involving  ISI  and  ourselves  only.  These  experiments 
were  mainly  concerned  with  the  data  input,  transformation  of  facsimile 
files  into  a canonical  form,  and  their  output  on  different  devices. 

The  work  done  during  this  period  resulted  in  a possible,  but  impractical 
system.  However,  it  has  provided  us  witli  the  necessary  information 
as  to  how  such  systems  should  be  designed  to  meet  the  requirements. 

Amongst  others  this  system  had  the  following  shortcomings: 

1/  It  was  heavily  dependent  on  the  UCL  PDP-9  and  used  too 
much  processor  time. 

) 2/  It  required  considerable  manned  intervention  and  was  awkward 

to  use. 

3/  Storage  and  Retrieval  aspects  were  explored  only  superficially. 

' Hence  the  Stage-2  work  was  planned  to  overcome  these  problems.  Unlike 

the  previous  work.  Stage  2 demanded  a Systems  Model.  Our  conceptual 
thinking,  and  how  we  have  attempted  to  realise  it,  are  discussed  in 


Socti  .n  10.2.  An  essential  pint  was  to  put  considerable  iiitelliyence 
into  the  facsimile  terminal.  This  v;as  .iccompli shed  by  putting  a 
microprocessor  betvjccn  the  standard  inalo^i  facsimile  device  and  the 
data  network.  Both  our  short  term  progress  and  our  long  t>^rm  plans 
for  tills  terminal  arc  discussed  in  Section  10.3.  A key  ingredient 
of  our  concept  is  the  use  of  aii  Inforimit  ion  Storage  and  Retrieval 
Node  (IR)  . For  this  purpose  we  are  using  the  Datacomp'uter  of  the 
Com.puter  Corpoi'ation  of  ,\merica.  In  .Sect  ion  I 0 . -1  some  of  the  operation 
of  that  machii\e  is  outlined  in  the  1 iuni  of  our  rec^u  i re?ments . Tnc 
status  of  our  ai.:tual  impl  enient  it  i on  i..  described  in  Sci'tion  10.5. 

One  specific  activity,  which  wi  IL  reguiro  further  extension,  is  that  of 
driving  ail  the  remote  s\'stems  through  tlic  intelligent  term.inal. 

•A  microprocessor  is  difficult  to  profjram.  In  order  to  be  able  to 
try  out  different  alternatives  more  simpl;..',  tlie  concept  of  a 
"Network  Access  .'lachine"  v;as  impl  cm.cmted  as  part  of  a separate 
project  described  elsewhere  (Kent  ,1  977)  . It  is  a subs'.'.stcn  whicii  runs 
inter.actively  in  the  I’DP9  , and  can  be  t;able-dr  i ven . It  al  iow.s  multi- 
user control  of  the  FAX  terminal  tm  one  hand  and  of  tiie  Dataconputor 
and  Messagi-  Processor  on  tiie  otiier.  For  small  si'ale  deployment  of 
different  types  of  FAX  terminal  , the  NAM  is  an  i ntorest  i rv.;  concept. 

It  permits  the  considerable  control  and  synchronisation  software  to 
deal  -with  all  these  systems  to  ie  centralised,  and  allov;s  a considerable 
simplification  of  the  software  required  in  the  FAX  terminal.  The  Xidl 
could  be  used  as  a networkwide  service,  support  iTw:  all  i'.AX-type  torr.inal 
Wo  are  pursuing  ttiis  apgaroacli , and  v;ill  describe  it  n.ore  fully  in 
the  ne.xt  annual  report. 

For  the  purpose  of  riemons  t r 1 1 i n<j  one  specific  FAX  system  implementation, 
it  does  not  provifle  any  funet  i ^>na  1 1 y superior  f ac  i 1 i t i cs . i’or  this 
reason  the  project  is  not  (.le.scr  i beil  in  detail  in  tins  lapoi't  . 

Finally,  v/o  have  iieen  investigating  fnrtlior  tiie  cvxinomie  implications 
of  the  type  of  system  outlined  in  Section  10.2.  Sever  li  Carriers 
have  announced  tariffs  for  piickel  switched  networks  (e.cj.  the  French, 

(JK,  Canadians  and  Telenet).  Rased  on  a comparison  of  these  tariffs  with 
the  traffic  flow  implied  liere,  v/e  have  tried  to  analyse  the  cost  of 
such  a solution  but  our  work  here  is  still  at  an  early  stage. 


I'll 


However,  it  has  clearly  shown  the  importance  of  three  factors  for 
facsim.ile,  namely: 


1 . Bulk  Rate  Discounts 

2.  Off-Peak  Rates 

3.  The  importance  of  integrating  the  Information  Storaae 
and  Retrieval  Node  (IR)  into  the  network. 


The  first  two  of  the  above  are  self  evident.  Even  with  a reasonable 
data  compression,  a full  A4  page  of  text  will  typically  require  25K 
bytes  of  data.  Even  with  optimum  packet  fill,  this  implies  a 
transaction  cost  of  I2c/page  on  TELENET  and  l7c./page  on  EPSS  ( at  peak 
tariffs).  In  both  cases  call  duration,  port  access  and  fixed  charges 
are  ignored  in  the  above. 

For  significant  traffic,  it  clearly  is  important  whether  the 
IR  is  integral  to  the  network  or  considered  outside  it.  In  one 
case  there  will  be  tv/o  impositions  the  transaction  charge  - one  to  the 
IR  and  one  on  retrieval;  in  the  other  case  only  one.  Clearly  the 
importance  of  this  factor  depends  on  the  amount  of  traffic,  the 
level  of  charges  for  IR,  the  ratio  of  transaction  cost  to  call 
duration  of  fixed  costs,  the  cost  of  message  processing  etc.  The 
analysis  of  the  impact  of  tariffs  on  this  application  are  sc  complex, 
that  we  have  started  developing  a computer  program  to  study  the 
effects.  This  program  accepts  as  input: 

Matrix  of  Transaction  Tariffs 
Matrix  of  Traffic  Volumes 
Vectors  of  Fixed  and  Time  Charges. 

Terminal,  IR,  Message  Processing  and  com.munication  costs  will 
all  be  considered.  This  work  is  still  at  an  embryonic  stage,  but 
will  be  discussed  more  fully  in  the  next  report. 

10.2  The  System  Overview 


In  principle  the  system  we  are  striving  to  develop  is  shown  in 
Fig  10.  The  UCL  facsimile  terminal  FAXl  is  connected,  via  the  TIP 
and  a character  terminal  interface,  to  ARPANET.  Also  attached 
are  an  information  storage  and  retrieval  system  (IR),  a message 


A 


I ■,  •. 


t .ICS  ini  lie  1 1 'rr'i  i . 1 
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s i:u;  .system  (Mi'l  in'i  .ui.  tl.t  i 
'I’A.XJ)  . There  is  no  ro-ison  wny  ‘-U’  ini'l  IK  siiould  ijt.‘  >ii.  different 
rs’i.!es  - but  they  ni;o(i  nut  m?ces.-;.ir  i 1 y i,<e  at  the  s.ine  one.  We 
v-niulti  like  to  develop  a system  where  the  facsimile  terminal  is 
sutficientiy  intelligent  th.it  it  cm  re.-ui  documents  wiUi  i text 
:a-..eiei  anii  address  lii.t;  the  f icsir.ile  d..ita  is  tlien  transrutteu 
lud  . toriai  in  IK,  while'  notitical  uin  of  the  sti)ra<^ji‘  of  the  document 
s passi.-el  to  .ill  .uldressi'es  via  MI’.  I.ater  ( lu'  .iddressees  mav 
i.-cess  IK  ind  rctriive  the  f i 1 1'  on  I lu' i r own  facsimile  device  (I’2)  . 

At  the  reeipiiuits'  optii’ii  (or  possibly  at  the  sender's  to  mimic 
"recorded  delivery")  each  iddi  essi'e  may  .uitomat  ical  ly  inform 
ttio  orHiiiKitor  th.it  the  doi'ament  v.i  is  received.  As  .m  added  fe.iture, 
we  wisli  to  sti  ri'  the  tacsiinile  ti.,it.i  in  a cainonical  lorm,  so  that 
It  may  be  rel.ru.vt'd  from  biiieii'nt  i.tcsirnile  di'Vices.  Thei  e is 
in  1 >r  t I n t difference  le'.wi  I'n  tile  iitor.iue  ..>f  L.  f u’sii.ile  and 
’ :it'  textual  i n loriuat  i on , I'm  tixtual  i nformat  i eii  is  sultI  - 
typii'aily  ies.s  tlian  100  livtc;  : ti.i.'  iaesimile  d.ita  is  much  It.'n-ier  - 

lypic.illy  J->K  bytes  for  ..ci  A-1  [.aae  with  optimum  d.ita  com|ressicn. 
lii'nce  the  textual,  d.it.i  e iti  be  stored  in  rault  if.de  c-pitc  - one 
1 >r  I ach  aiklressc’e  in  liii:  "M.i  i Ibe'.x"  . The  f.icsimili  i n f c i r.iat  i cn 
m.  store. 1 only  r.nei  in  IK  - ,uui  the  [>ath  n.imc  to  i • i leve  it  is 
xn.'  wn  ij\  tiie  ackii  es.sees  1 n : i tlieir  te.xt  messaiji';. . 

In  .in  attempt  to  implemcn*  this  system,  v/o  have  u.-.e..i,  cf 
einirs'.,  .■d<i’/vNbT  .is  the  d.ita  network.  For  FA.Xl,  we  ictacned  a 
;■  I cr ■ roces.sor  tc-  .in  .inab.ii  -1  •.  monit<  r facsimile  device  (Secticn 
1 .'.3;;  tl'ii.s  was  then  ce>ntu'',’t i-ii  via  m .i syne'h ronoii.;  .:..t.i  link  to 
til'  .'1,  ’111’.  We  i.iund  th.it  it  w.is  impossible  to  p is.-i  1 in.ir-.'  data 
it  aii_.  re.  1 son.ib  1 e'  sj  i-.-  i Lhrou<|h  the  '1' 1 1’  I'ha rac tc'r s ports.  Fnder 
■‘if  Ml.  e I rcumst.inces  (wtiieh  we  underst.iml)  the  TIP  ■■•^ou  la 
i t-a.ill/  lose  ch.ir.icters . While  tlu‘  m i cro|)roce.ssi'r  w.ns  informt'd 
• ! t:..  1 ,ie't  (b'/  a Bell  cli.iractor  beimi  eelioe'’d  bac'k)  , it  was  not 

P'lssil..  j.  te  fell  loe.ilLy  tn 'w  m.my  eh.irat'ters  had  been  lost.  In 
f i-'t  ;t  wis  quite  .iildliMiy  whether  one  f.iarticular  cluiracter  had 
men  trinsnuLLeii  or  not.  For  this  reason  attachinq  the  UCb  FA.X 
I-  tcfi  i lie  to  the  'i'll'  ch.irae’ter  p.  .rt  had  to  be  .iband arieii . i’or 
; mf.  1 i • 1 ty  , it  w.is  .itticheii  in.stcad  to  one  UCL  I’lll’v,  -o  la  an 
ii.t-ir;  ic<-  jirotocoi  sliqiitly  modified  from  the  RSKF  ene  (vSection  2.. a). 

I 


tor  the  ,41*  ol  | i<(  10.  I , we  vi.si'd  .i  Tenex  (usuil  ly  1 ;!  1 ) runniru) 


the  Message  system  MSi,'..  \s  far  as  [possible  we  will,  for  tlie 
time  being,  use  MSt;  unehaiigeJ  anti  try  to  assess  which  feafares 
in  It  are  really  required  for  our  ai)(i  1 i ca  L ion . For  IK  tlie 
UatacompuLer  at  CCA  is  a naturvil  camiidatc,  and  has  been  used 
exclusively.  As  FAX2  w._>  will  eventually  use  an  XGP  on  ARP-AN’KI  , 
iS  we  did  [jreviously  (Kirstein,  l97bA)  . It  will  probably  be 
controlled  a<.jain  by  a 1>1)P  i'enex  - I'DP  1 1 conf  igur<i  t ion , because 
that  is  the  way  the  software  to  drive  the  XGP  has  lieen  iniplementeu . 

An  independent  resoarcti  project  iris  been  under  way  for  a 
couple  of  years  to  establish  a Netv/ork  Access  Macliine  (.\'AM)  . 

It  seemed  to  be  an  excellent  a[)plication  of  the  X'AM  to  use  it  to 
automate  the  functions  of  controlling  tiie  connections  to  the 
Data  Machine  and  the  Message  Processor.  The  systesrs  overviev; 

With  and  without  the  NAM  with  wliicii  we  have  been  working  is 
sliown  in  I'icj  10.2.  At  tiie  end  of  107fi,  tlie  text  stroeun  was 
not  even  t)OLmj  from  the  m icrojirocessor  (yP)  to  the  PDP9 , but  was 
going  directly  to  a 'I'lP  character  port.  This  was  ilue  to  software 
limitations  in  the  PDP9.  I.'vent  ua  1 1 y , however,  tliere  will  be  a 
simple  dialogue  between  user  ami  |iP , and  the  l.itter  will  auto- 
matically open  connections  to  the  DC  and  MP , send  tlu'  appropriate 
te.xt  to  MP  and  binary  facsimile  data  to  , and  ttien  close  down 
the  connections.  With  the  NAM,  the  paths  look  the  same,  but  the 
control  functions  are  e.xercised  by  the  NAM,  which  runs  in  the 
PDP9,  rather  than  in  tin  . 

10.3  Th('  I'ser  View  of  the  .dystem 

10.3.1  I lA  roduct  ion 

A systei:  like  tiie  one  here  can  bf'  describeti  at  many  tiifforent 

. eve  1 . In  this  sc'ctien  we  will  describe  the  facsimile  terminal 
.tm.lf  (Seetion  10.  1.2)  and  the  User  Dialogue.  Althoucjh  the 
pre.sent  facsimile  tc-rm  i na  1 consists  of  only  a slow  4 n minute 
facsimile  ilevico  front -endi'd  by  a microprocessor,  tlie  system 
w.Il  bo  uncliangeil  when  it  is  replaci.'d  by  an  all  diijitaJ  system. 

The  user  di.ilocjuf'  has  one  portion  for  document  transmission 
(Sect  man  10.3.3)  and  one  for  document  retricv.il  (Sc'ction  10.3.4). 
Tne  document  transmission  dialogue  is  m.iinly  eonceriu'd  with  the 
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composition  of  a text  mossa^je  to  the  MSG  message  systeni;  the 
binding  of  the  linkages  to  the  Datacomputer  and  the  supervision 
of  message  transmission  to  both  is  almost  transparent  to  the 
user. 

The  retrieval  node  can  have  one  or  two  stages.  Because  the 
notification  comes  via  tlie  text  message  system  MSG,  the  user  may 
receive  notification  of  the  availability  of  facsimile  files 
during  straight  forward  text  retrieval  from  a conventional 
terminal.  Tlie  facsimile  document  retrieval  must  then  be  a 
separate  exercise.  Alternatively,  the  user  may  access,  via  a 
somewhat  simpler  dialogue,  MSG  via  the  facsimile  terminal.  In 
this  case  the  notification  and  retrieval  will  be  an  integrated 
operation.  We  do  not  have  space  to  enumerate  all  the  facilities 
of  MSG  - they  are  all  available,  liowever  to  forward  notifications 
to  whole  lists  of  addresses,  answer  messages  and  similar  functions. 

10.3.2  The  f’acsimile  Teianinal 


Prior  to  a description  of  the  details  of  our  implementation, 
an  overview  will  be  given  of  a typical  users  dialogue  in  our 
model . 

The  facsimile  terminal  i,FAXl)  is  sketched  in  Fig  10.3. 
Physically  it  consists  of  a Plessey  4/6  minute  analogue  facsimile 
device  (FAC)  attached  via  a simple  A/D  2 level  converter  to  a 
24K  8 bit  word  INTFb  8080  microprocessor  (yP) . Also  attached 
at  present  is  a floppy  disk,  a keyboard  terminal,  and  two 
asynchronous  channels  are  attached  to  the  TIP  and  one  to  the 
PPDP9  - because  we  liave  had  some  temporary  software  problems  in 
multiplexina  two  streams  over  the  PDP9  - vjP  interface,  but  this 
will  be  remedied  early  in  1977.  Two  asynchronous  format  channels 
were  used,  because  we  planned  to  enter  via  the  TIP  terminal 
ports,  these  would  only  support  that  format,  and  would  only 
have  one  virtual  connection  over  each  port.  With  our  abandonment 
of  this  approach,  the  uP  now  connects  straight  to  the  PDP9;  it 
would  now  be  natural  to  use  a single  synchronous  interface 
and  also  to  multiplex  the  control,  text  used  and  facsimile  data. 
This  we  will  do  eventually.  Conceptually,  therefore.  Fig  10.3 

shov/s  both  the  [^resent,  and  planned  configuration 
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The  standard  4/6  minute  analogue  facsimile  devices  must 
first  synchronise  with  each  other,  which  takes  up  to  15  seconds, 
and  then  read  a full  page  at  a time  without  interruption.  It 
is  impossible  to  guarantee  any  specific  data  throughput  via  a 
packet  switched  network  like  ARPANET,  therefore  data  is  staged 
always  via  a floppy  disk.  At  a later  stage  we  can  plan  to 
replace  the  analogue  facsimile  device  by  a digital  one,  in 
which  case  the  data  flow  can  be  interrupted  after  each  scan 
line.  In  this  case  a floppy  disk  should  no  longer  be  necessary. 
However,  a backing  store  may  still  be  desirable  for  other  reasons 
(see  Section  10.5.2). 

As  described  (Kirstein,  1976A) , the  analogue  data  is  passed 
through  a simple  threshold  detector,  sampled  at  about  2.4K  bps, 
and  the  data  output  as  a synchronous  series  of  eight  bit  bytes, 
though  with  asynchronous  format  (start  bit,  eight  data  bits, 
stop  bit) . This  allows  standard  communications  interfaces  to 
be  used  between  the  FAC  and  the  jaP.  A synchronous  data  adaptor 
will  be  used  eventually  instead  of  the  asynchronous  one.  This 
is  more  appropriate  for  the  usual  situation  where  the  terminal 
is  remote  from  the  network  and  must  use  medium  speed  data  trans- 
mission facilities. 

The  keyboard  is  needed  to  control  the  system,  and  add  addressing 
and  document  naming  facilities,  for  document  transmission  and 
retrieval.  In  our  case  a standard  teleprinter  is  used.  In  an 
operational  system  a simple  keyboard  and  cheap  20  character  wide 
printer  would  be  quite  adequate. 

10.3.3  The  User  Dialogue  for  Document  Transmission 

A typical  user  dialogue  for  transmitting  a 5 page  document  is 
shown  in  Fig  10.4.  A commentary  on  this  dialogue  is  given 
below  : 

1 . Start-up 

The  facsimile  system  resides  on  a floppy-disk,  and  it  is 

loaded  into  the  memory  by  typing  an  'L'  on  the  user  console. 

It  then  initialises  itself  and  prints  out  the  title  and 


DIALOGUE 


C0MMI':NTS 


$ _L<CR> 


***  UCL  FAX-MESSAGE  SYSTEM  VERSION  X.0  4 * * *~^ 

YOUR  NAME:  K ]_KSTEIN<CR>  ^1.  Logo-n 

PASSWORD:  XYZ  <CR>  ^ 

LOGIN  O.K. 


. . . TYPE  ? CR  FOR  HELP 


2.  Optional  User 

Guiaai'.ce 


$C  <CR> 


COMPOSE  A FAX  MESSAGE  FILE 
TO : KIRSTEIN  at  ISIA _<C10 

CC  : YILMAZ  at  BBN ^ <^2. 

NAME : FAX_  DOC  ■ 1 

NUMBER  OF  PAGES:  b ^CR^ 

INSERT  THE  FAX  DOCUMENTS  AND  TYPE  YOUR 
MESSAGE 


3.  Addressing  and 

naming  the  doc'oment 


Document  Feeding 


THIS  ^S  A TEST  MESSAGE  SENT  BY,  FA^^IMIL^ 
SYSTEM  AT  UCL  <CR>. 


5.  This  message  is 
composed 


tz 

TEXT  IS  O.K.  KIRSTEIN  AT  ISIA 

YILMAZ  AT  BBNE 


Sending  the  message 

Delivering  confirm- 
ation of  text 


FAX  IS  O.K.  8.  Delivery  confirm- 

ation of  facsimile 
data 

Fig  10.4  Dialog\ie  for  sending  a docimicnt 

(C'haracters  input  by  user  are  unuerlined.  Carriage  Returns  indicated 
by  <CR>) 
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the  current  version  number,  and  asks  the  user;  his 
name  and  password  to  perform  the  login  procedure.  If 
the  login  is  successful  it  prints  out  the  FAXSYS 
prompt  characters  and  waits  for  a command  input 

as  shown  below.  For  subsequent  facsimile  operations, 
this  portion  of  the  dialogue  will  not  be  repeated. 

2.  Help 

<- 

If  a ?<CR>  is  typed,  a Help  file  is  produced  on  the 
console,  giving  information  on  the  use  of  FAXSYS 
commands . 

3.  Addressing 

This  indicates  the  addresses  of  notification  about  the 
availability  of  the  document  and  the  short  text  message. 
The  Document's  name  is  chosen  to  be  informative;  it  will 
be  printed  out  later  for  the  recipient,  but  is  not  used 
to  identify  the  document  (see  Section  10.3.5).  The 
identification  number  is  composed  at  this  time,  so  that 
the  complete  subject  field  for  MSG  is  formed. 

4.  Document  Feeding 

At  this  point  the  facsimile  document  is  inserted  into 
the  machine  for  scanning.  While  the  text  message  is 
being  typed  in,  the  scanned  data  is  processed  and  stored 
on  the  floppy-disk. 

5.  Message  Composition 

The  FAXSYS  provides  three  editing  characters  which  may 
be  used  to  correct  errors  during  this  period.  These  are 
tA  to  delete  the  last  character 

tW  to  delete  the  current  line 

TN  expunge  message 


lit.'ie  Tn  nu.ans  CONTROL  aiici  A pr-.'sscd  j.inui  taneousl  y etc. 

"Ia  and  'I'W  can  be  used  repeatealy,  and  1'n  ailav.'u  tbe 
del‘~-tion  cf  the  entire  message  for  a fresh  start. 

While  different  control  characters  could  have  bee.n  used, 
since  they  are  pro»:esscd  in  the  inicropicssor , it  '^as 
thought  desirable  to  be  consistent  with  the  MSG  subsystem 
of  the  Tonex.  lor  the  same  reason  tA'o  other  co.mjnaads 
are  used: 

t K type  cui  ‘eat  Line 

"t S type  current,  mess.-' 


6.  Message  Transmission 

This  chara;-tor  signals  the  messaq>.  sh'auld  be  transmitted. 
•At  t.his  point  a'i  t.he  standard  ,MSG  facilities  for 
immediate,  dc  laye-J  or  queued  transmission  may  be  invoked, 
since  MSG  v/ill  be  used  diri'ctly.  Tire  whole  niossage 
■ can  be  si.;nt  in  om  ourst  at  tins  time. 

7.  Text  Delivery  Confirmation 

The.se  replies  w,.li  come  directly  from.  MSG,  and  thus  all 
their  options,  such  as  non-delivery,  queued  delivery, 
etc.,  may  arrive. 

8.  This  is  the  successful  response  code  from  the 
Da tacomputer  as  interpreted  by  the  UP. 

10.3.4  The  Dialogue  for  Text  .and  Facsimile  Retrieval 

Since  the  text  portion  of  the  facsimile  system,  uses  the  MSG 
system,  it  can  be  retrieved  on  any  alphanumeric  terminal.  Thus 
the  recipient  of  a text  message  may  access  MSG  on  the  Tenex  which 
he  uses  for  text  messages  in  the  normal  course  of  his  work.  In 
this  case  his  dialogue  may  well  follow  the  form  of  Fig  10.5. 

After  logging  in  (1)  and  invoking  MSG  (2),  he  is  informed  that 
FAXUOC  1 of  length  5 pages,  is  v/aiting  for  him  at  CCA.  This 
header  has  been  devised  from  the  NAMF  (FA.XDOC.  1)  and  the  length 
(5)  input  at  phase  (3)  of  Fig  10.4.  The  number  in  paranthescs 
i.s  a Datamachine  reference  to  the  file. 


He  may  still  wish  to 


1 


00  86  <CR> 
Tryiny  . . . 


Open 


ISI-TENEX  1.34.10  ISI-SYSTEM-A  EXEC  1.04.10 
LOGI  KIRSTEIN  (PASSWORD)  (ACCOUNT) 

JOB  32  ON  TTY  11  10  JAN  77  16:20 

PREVIOUS  LOGIN  4 JAN  77  04:31 

[you  have  new 

MSG  --  Version  of  1 April  l‘)7(> 


- + 29  4 Feb  KIRSTEIN  AT  ISIA  - The  Document  FAXDOC  (5  payes)  is 

available  at  CCA  (77021009255) 

LAST  READ;  4 Jan  77  04;  3b;  25;  28  Old  Mesy . 29  Mesy  28  disl;  pages. 

Old  not-examined  msys.  exists 


Type  29  <CR> 

Mail  from  ISIA  revd  at  lO-Jan-77  0952 
Date:  10  Jan  1977 

From  Kirstein  at  SRI-Al 

Subject:  The  Document  FAXDOC  (5  pages)  is  available  at  CCA 

7702  1 009255 

To:  KIRSTEIN  AT  ISIA 

cc:  YILMAY.  AT  BBNE 


THE  F/vCSIMILE  DOCUMENT  NAME  IS  AVAILABLE  AT  CCA.  IT  MAY  BE 
REgUESTED  AS  77021009255.  IT  IS  OF  .LENGTH  5 PAGES. 


THIS  IS  A TEXT  MESSAGE  SENT  BY  THE  FACSIMILE  SYSTEM  AT  UCL 


Fiy  10.5.  Dialogue  for  accessing  the  Message  Processor 
(Character  input  by  user  is  underlined) 


inrl  qo  thr';''uqu 


see  if  t.iore  is  an/  interest  inq  t ext  for  ti: 
the  steps  of  Fiq  10. '3.  It  is  shovjrx  t;.at  the  i irst  part  of 
the  message  has  also  been  composed  aatomat  ica  1 ly  from  the  se.nder 
name,  the  document  name  and  the  document  Length  entered  in 
phase  (3)  of  Fig  10.4.  At  this  stage  the  user  can  call  all 
che  processing  facilities  for  MSG,  and  can  file,  delete,  forward 
or  move  the  text  message. 

To  retrieve  the  ..letua ! t;ocur:icnr , he:-  must  ns..  Iris  racsiinile 
terminal  (FAXl)  of  Section  iO.J.2.  Here  the  dialog.'*  follow.s 
much  the  san-  j.'ULtern  of  Fig  10,4,  as  is  ij..,.!..  .r.ea  o-ti  Fig  10.6. 
An  explanation  of  tiio  di.iiogue  jn  given  helow: 

1.  Tills  IS  the  same  login  to  i.ht  facsimile  terminal 
as  in  Socti'on  1C  . r3- 

2.  This  connects  to  MSG.  At  (.resent  only  ISIA  can 

be  acc'cssed:  eventual  ly  HOST"  will  connect  to 

MSG  on  spei.'if-i  - nest. 

3.  Novi/  ^ho  user  Is  eouncete.i  to  MSG  at  IGI.^,  and  all 
normal  MSG  e..;.  "t.iiris  could  ee  followed.  Thus  if  the 
user  had  lut  yet  accessed  MSG  before  through  an 
o]-d.ir.aiy  teridnal,  he  would  have  use  "H”  for  listing 
h€'ad(.’rs,  "F"  and  "1-"  for  lorwird  and  delete  etc. 

By  prefixing  a command  'vith  ?,  to  indicate  a 
communication  'with  the  terminal  system,  in  this 
case  he  requests  facsimile  file  29  to  be  retrieved. 

4.  The  facsimile  terminal  indicates  the  title  of  the 
document  and  its  length  - retrieved  from  ISIA.  It 
also  obtains  the  [lointer  to  the  file  in  the  CCA 
directory  (77^2 1 JI1I9255  1 ) . Its  computation  is 
discussed  belc.'w. 

1.  On  confirmation  tnat  the  file  of  (4)  is  the  correct 
oi'n  , it  is  i'l'tricvcd  and  kept  on  disk.  If  $P  had 
been  Input  in  (3),  the  file  would  also  have  been 
output  on  the  fac.simile  terminal. 
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Ct:R-> 

UCL  FAX-MKSSAGU  SYSTEM  VERSION  4 
YOUR  NAME:  KIRSTEIN  <CR^ 

PASSWORD:  XYZ  ^CR> 

LOGIN  O.K. 


;ZM^CR^ 


MSG  ....  VEi<SlON  OF  APRIL  1 1976 

Last  Road  10  Jan  1077  29  old  nisg  28  disk  Pages 


34R  29<CR> 


TRYING 

KIRSTEIN  FAXOOe  (S)  770  210092551  (CONFIRMj  <.CR> 


....FAX  Mi:SSAGE  RECEIVED 
>?E  <CR> 


Fig  10.6 


Dialogue  for  Retrieving  Facsimile  Files 
from  the  Datacomputer 


s Iri  1 


me- s sane 


user  yivf's  the  <..’?>  command  co  exit 
from  MSG  and  close  down  the  network 
connection  to  the  Datao'omputer . 

It  should  be  noted  tiiat  .1m  actually  connects  the 
facsimile  torr'itijl  i MS(j.  i'or  this  reason  the  dialogues 
of  StcOgcs  (11  of  K 1 q 1 0 , conU";  huve  been  replaced 

by  Stages  (2)  and  [2)  of  Fii  10.6  - and  1 un-'ead  message 
title  09  would  still  have  appeared  pr vr 1 ed  on  the  terminal, 

lO.l.t  Generatior  cf  ^’ess  ige  f ode  l.'oiiibers 

The  link  betwi-en  1 he  i>_-M  and  t;.e  facsimile  messages  is 
formed  as  follows: 

During  the  iiOGjM  ...  [nrriod  the  sy';tem  obtains 


the  time  and 

dcite  cf 

l.OC  . l, 

wh  ieh 

■|!j'  t.he  format 

DAY  - MON  Pi! 

- YEAR 

HOURS 

- .MIt;UT 

i.S  - SECC.NT.S 

(e.g.  10- JAN 

-197" 

1 ' 0 ; 2 5 

; 5 1) 

This  Information  is  'o-.  rj anged  to  form  a twelve  digit 
number  whit'ii  is  unitiue  to  tiie  n\essia--;e  2seln;j  sent.  Tor  the 
example  giver,  above  this  cod(>  number  bccones: 

7702  J 0092551 


\ 


> 


It  is  essential  th.il  <i  uniijue  number  lie  formed,  so  that 
messaejes  c.an  be  retrieved  uniquely. 

This  code  number  is  added  into  the  text  message  header 
before  transmission.  This  code  is  retained  and  used  with 
the  KIRSThIN  to  store  the  corresponding  facsimile  file  at  CCA. 
At  the  end  of  the  operation  detailed  ,n  .Section  10.3.3  the 
Kirstein  node  now  contains  a nev/  entry  as  demonstrated  oelow 
FACSIMILR 

I ST 

KIRSTEIN 

770210092551 


If  certain  sites  desire  to  be  particularly  secure,  tiiey 
may  set  a site  password  at  that  point  in  the  path.  More  usually, 
only  the  users  will  be  given  password  protection.  Thus  to  access 
a file  FAXDOC  by  a user,  KIRSTKIN  whoso  MAILBOX  is  at  ISIA,  and 
whose  password  is  SECKLT  would  bo: 

LOGIN  FACSIMILE 

: LOGIN.  KIRSTEIN  (SECRET).  FAXDOC 

If  we  desire  e.xtra  security,  so  that  the  facsimile  system 
itself  and  the  site  ISIA  tiuve  protection  passwords  FAX  and  SITE, 
the  equivalent  command  would  be 

LOGIN  FAGS IMILE  { ' FAX ' ) 

'LLOGIN.  ISIA  (SITE).  KIRSTEIN  ( SECRET)  . FAXDOC 
Not  o.nly  will  notification  of  the  e.xistence  of  a file  be  sent  to 
an  addressee's  mail  box,  but  also  a READ  privi ledge  will  be 
given  to  that  addressee  as  the  file  is  created.  Tlius  tlic 
addressee  will  later  be  able  to  CONNECT  his  facsimile  terminal 
to  the  file  via  Ins  node. 

10.4  Storage  and  Archival  at  CCA 

10.4.1  Characteristics  of  the  Datacomputer 

The  Datacomputer  is  shared  larcje-scale  data  storage  utility 
offering  data  storage  and  data  manacjemcnt  services  to  other 
computers  on  ARPANET.  The  system  is  iritondod  to  be  used  as  a 
centralised  facility  for  arcliiving  data,  for  sharing  data,  among 
the  various  network  ho.sts,  and  for  providintj  inex[)ens ivn^  on-line 
storage.  The  DatacompuLer  is  implemented  on  dt'dicatod  hardware, 
and  comprises  a sc[)arate  computing  system  .s]jecialised  f('>r  data 
manacjeiufmt . Logically  tl\e  system  can  be  viewed  c\s  a closed  box 
•siiared  by  rnultipli.'  external  processors  and  acctuu'u'd  in  a standaLxi 
notatifui  called  Da  ta-l.an(|ua<)C‘ . The  system  is  provided  with  an 
Ampex  Tc.'rabit  store  of  4 x 10  ' 'bits.  While  this  is  iiiainly  used 
for  seismic  dat.a,  it  does  cc^ntain  software  and  liardwarc  ideal 
for  archival  storage.  Tiius  it  is  an  excellent  vehicle  for  our 
exjjer  iments . 

In  Section  10.4.2  we  discuss  briefly  the  data  stiuctures  sot 
up  in  the  Datacomputer,  and  tiu'  way  files  can  br-  accessed.  In 
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Section  iO.i.j  cr.<:  Data-Ijanquacc  coed  to  cri/e  che  naciiine  is 
mencionod.  Little  detail  is  ijiven  in  tills  section  of  iiow  user 
facilities  aic  tJ.uans  L.itt'd  into  Uata-Lanquaqe  dialoque. 

10.4.2  Directory  .Structure,  Privacy  and  File  Access 

The  general  structure  ot  files  in  the  Dacacomjjuter  is  a tree  v.'ith 
nodes  nested  to  .m/  depth.  To  access  any  specific  node,  it  is 
necessary  to  ANCHOR  Mie  user  to  a node  higher  up  tiie  tree,  and 
to  .ATTACH  to  the  nolle  through  a specific  putli.  It  is  possible 
to  assign  LOGIN  in  privilege  via  passwoid  protection,  and 
CHANGE  privi  le-g<.  at  <iny  node.  It  may  also  regu  i re  passwords 
to  travel  down  the  tree  tniough  any  iioue.  I'lnaiiy  eacii  tile  can 
be  printed  to  only  tin  ougii  a node,  and  rail  i)C  jiven  READ,  V.'RITE 
and  Al’PEND  privilego  al.so  urvior  passwoi'd  i;:ontrol  . If  no 
privacy  is  ncces..ary,  then  i'  is  nccessuiy  only  to  set  up  one 
node.  Ail  users  wiio  ue  g.ven  access  to  th.at  node  would  also 
be  able  to  access  any  file  in  the  director^-.  Password  protection 
could  still  be  aj-iplied  to  tiio  “^iles,  tlius  it  would  be  possible, 
if  the  .sender  knew  the?  passwords  of  all  adircsses,  to  give  RI.AD 
privilege  only  to  t neni  - but  he  could  then  read  all  the 
addresses  files!  In  order  to  give  a much  greater  degree  of 
privacy,  it  is  po.ssiblc  to  use  the  provisions  built  into  the 
Data-Language . A sfiecial  FAC.SIMILE  directory  is  formed,  with 
nodes  correstionding  to  the  notification  box  site  and  User  name. 

The  l-ACSiMlLE  directory  on  the  Uatacomputer  is  a tree,  with 
the  FACSl-ilLE  iiotlc  at  the  top,  site  nodes  under  PACSIMILE,  user 
nodes  subordinate  to  the  site  nodes,  and  facsimile  files  beneath 
user  nodes.  A user's  name  space  may  be  further  divided  into 
sub-directories  of  arbitrary  depth.  PictorialLy  this  is  illustrated 
in  Fig  10.7. 

FACSIMILE 

/ \ 

SITE  SITE  

/ 

user  user  user  user  

FILE  liUB-DIRECTORY 

FILE  SUB-DIR 

/ \ 

FILE  FILE 


Fig  10.7 


Uir<'Ctory  Structure  Cor  Facsimile  File 


Any  node  in  tiie  directory  can  be  accessed  via  a generalised 
means  for  specifying  directory  paths.  The  mechanism  consists 
of  an  anchoring  point,  for  name  references,  and  a path  name, 
winch  is  tile  segui'nce  of  noile  names,  starting  at  the  anclior, 
defining  t lie  desired  brancii  of  tlie  directory  tree. 

There  are  three  contexts:  tiie  Top  Context,  the  Attach  Context, 

and  tile  Connect  Context.  Tiie  To[i  context  ancliors  tiie  patlinanic 
at  tiie  facsimile  node  and  is  used  primarily  for  referencing  tlie 
other  user  nodes.  Tiie  Attaeli  Gnntext  is  a path  wliicii  is  set  by 
thefacsimilc  system  automatically  at  the  beginning  of  a session, 
and  ends  up  with  a user  node.  The  Connect  context  is  a path 
winch  is  initially  set  as  the  Attacii  context  and  terminates 
in  a sub-directory. 

10.4.3  Use  of  tiie  D.itacomputer 

Tiie  Uatacomputer  is  desiijned  so  tliat  external  computers  may 
transfer  data  bet  wei'ii  themselves  atul  tlie  Datacornputer  (DC)  by  a 
two  stacje  process.  i'irst  tiiey  connect  to  one  stream  in  tlie 
system  by  tlie  standard  "initial  Connection  Protocol"  of  ARPANET 
followed  by  a LOGIN.  Tiiis  connection  must  bo  active  tliroughout 
the  data  transmission.  It  is  used  to  control  the  data  transmission 
and  set  the  appropriate  transmission  parameters:  we  will  call  this 
stream  the  "Control  .Stre.im”  (CS)  , Wlien  the  control  stream  has 
been  set  up,  and  tlie  aiipropriate  ptitii  to  tlie  user  node  follo'wed, 
a second  data  strcxim  (DS)  is  opened  by  CS.  All  data  transfer  is 
tiirougii  tliis  data  si  rixim  (OS)  . An  exiimple  is  given  in  Fig  10.8 
of  tlic  commands  reguiretl  to  lot|  in  and  retrieve  a file  FAXDOC 
sent  to  KlKSTfilN.  it  is  assumed  tliat  tlie  retriever  is  usincj  a 
Til'  <ind  'Wishes  t ht'  data  to  come  (into  [lort  2(i2l4h  of  tlie  TIP.  In 
trie  exangde  tiie  passwonis  PASSIVORD  and  SECRET  neciled  to  access  tlic 
lACSIMlEE  and  KIRSTEIN  nodes,  and  it  is  assumeci  tlie  ISIA  notle 
(ioes  not  require  .1  password  (see  fill'  structun.'  of  Fit]  10.7). 


The  Data-Eanquuge  (DE)  is  a clc.irly  dofineii  dialogue,  witii 
a numeric  prjrtion  designed  for  computer  ratlier  tlian  luiman 
processing.  llowr-ver , Fig  10.8  sliows  it  is  possilile  It''  drive  the 
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Da  taconij.  uter  irain  /.tiyLoard  terminals.  If  * no  'Character  ports 
on  the  Til'  ire  used,  two  torniinais  and  their  ports  are  required 
one  Cor  the  control  stream  and  one  for  the  data  stream;  tne 
TIP  software  does  not  permit  two  virtual  circuits  to  be'  activated 
simultmeous ' y from  one  terminal  port. 


The  DaLa-Lam;ua'je  is  very  awkward  for  iiuman  users,  a.nd  verbose  - 
one  example  f tlie  diaioque  for  o'/on  a simple  operation  such  as 
Loyin  is  stiown  in  I’ij  1 0 . h . Here  the  underlined  lino  is  the 
user's  commanti,  t.he  otiiers  arc  the  Datacomputor  replies.  A 
complete  descri;jt  ion  of  the  whole  languaye  is  shown  m (CCA,  1976). 
One  reason  ti;c  the  L’at.i-i.anquaqe  diaioque,  illustrated  in  Fig  iO.9, 
looks  so  voibose  is  just  that  it  is  well  structured  for  machine 
processing.  The  first  set  of  figures  is  Data-Language  response, 
the  second  tlic  data/time  and  tiie  third  data  is  human  readable 
format  and  a verbal  description  of  the  commands.  While  the 
Data-Language ' responses  may  be  verbose  for  humans,  they  are 
excellent  for  synchronising  ictivities  witi;  another  computer  or 
intelligent  terminal.  They  gav-.  just  the  right  information  on 
successful  complel ion  and  error  conditions. 


<5  H 11  <CR> 
R F L ^-CRe 
(d  I I”  P <CR> 


J 


Connect  to  socket  of 
Datacom.p'uter 


LOGIN  FACSIMILF  ^"PASSWORD");  <CR> 


J 


Log  on  to  Datacomputor 
and  connect  to  FACSIMILE 
node;  pass  to  KIRSTEIN 
node  and  prepare  to  re- 
trieve . 


OPEN  ?,  LOGIN.  KIRSTEIN  (SECRET).  FAXDOC  ; 
CONNECT  FAXPORT  262146;  'CCR^ 

FAXDOC  = FAXPOR.T  ;*  CRv  / 


<CR> 

Connect  file  to  TIP 
data  socket. 


CLOSE  FAXDOC;  ' CRw 
DISCONNECT  lAX  PORT;  CR 

(i  C <CR> 


Close  File 

Disconnect  data  socket 

Disconnect  from  Data- 
computor 


Fig  10. a 


Data-Language  Commands  to  Retrieve  and  File 


H 31  • CR> 


Ci'imect  to  a froo 

socket  at  tiio  dat  acer.'.eutor 


^ R F S 30  3 - ek 

-d  I C P • C_R  > 

Trying 

Open 


( Da  ta-Lan<iuage  resj )on;u’;: ) 


j ;0031 

770  110  1 1592S 

lONLTl : 

CONNECTED  TO  LONDON-TIP- 1 "’00000 

1 ;J150 

7701101 3 59 20 

FCRUN: 

JANUARY 

V=  ’ 0('-  1/01.13'  J - 1 DT=  ' MONDAY  , 
10,  19  77  08;  59  : 20-,'st  ■ s='CCA' 

o 

o 

770  1 10  1 35920 

ONCINX: 

DATACOMPUTER  GOING  DOWN  IN  2808 

1 ;J200 

7701101 35920 

RllRUN  : 

READY  FOR  REOUEST 

.12  10 

7701  10  1 35920 

LAGC  : 

READING  NEW  DL  BUFFER 

; LOGIN 

FAC  SIMILE  CPAS 

SWORD'  ) ; F 

R 

( Da ta-Lan<jua<je  responses ) 


; 00  3 2 

770 1101 40028 

AS PR  IN 

HOST=' LONDON-TIP ' SOCK= 1200000 

; 0033 

770 1 10140028 

A SLOG: 

USER= ' FACS IMILL ' 

; J209 

770 110140028 

RllRUN: 

EXECUTION  COMPLETE 

; 1200 

7701 10140028 

RllRUN 

READY  FOR  REQUEST 

.1200 

770110140028 

LAGC  : 

READING  NEW  DL  BUFFER 

Fiq  10 

.9  Dat.icompijte 

't  Lo<j  i n 

Procf'dur  e 

n . 5 

The  IICL  InipleriH’ 

■lit  at  ion 

In  Sfjftion  10.2  we  have  prc'senta'ci  an  overview  of  what  we  arc  jj 

trying  to  achii've.  In  Section  10.3  we  iiave  outlineil  how  the  user  ' 


! 
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should  see  t)ii>  system  and  in  Section  10.  i how  the  Datacomputor 
can  be  used  to\*  iniormation  storage  and  retrieval  v/ith  appropriate 
privacy.  Nov  we  wil!  describe  briefly  the  UCL  implementation. 

It  is  clearly  inappropriate  to  give  much  detail  here.  In  Sections 

10.5.1  and  10.5.2  ttie  actual  hardware  configuration  and  the  software 
structure  ar<-  ment  roned  briefly.  In  Section  10.5.4  ttie  status 
or  tne  implementation  i-  reviewed. 

10.5.1  Tin.'  I'.ii'  w.ir  • ‘ ’onr  igur.it  ion 

The  UCL  n.ir  (!.vX)  a.ts  been  desci  iluni  ,t'.  Ludy  in  Seetion 

1 0 . 3 . .1 . n oui  iM  , I i I-  i:i'ents  we  af  a ’f.ud  the  fetcsiuiile 

terminal  to  tv;.'  ai  il<  o.ynclironou.';  tc.:.  i r > is  of  the  TIP; 
this  wets  to  ill  '.no  r.'-ii.rol  .nd  d.it..  streams  of  Section 

10.4.3  lo  1..  . '1  1 n-t  wc  founu  t-.it  the  TIP  pert  could 

not  be  used  . . ; . * i • civ  _•  .ny  • • ed . The  flow  control 

IS  very  p.  ..  , ir-  ; • i.i  ” iiij  i .n-t  i.mI  t..  devise  a scheme  for 

overconurw  r.  . .r  •har  ‘.'I  t undi.'r  specific  conditions. 

For  tins  ) c.i.  !■  ••  t'  end  >;  I ‘76  was  based  on  tne 

facsimile  tile’ll  ’t  ■ ..e  all  t..f  di  'logue,  but  the  actual 

V>aths  iiad  Lh>'  i t v.  i a TIP  cP.  ir.ictei  port  path  for 

control,  ami  ' i n ' : i .lata.  Wc  are  m.  a fying  the  FDP9/FAX 
software  in'-.  il.i-'  ' ■ mat  the  stream. ^ to  be  multiple.xed  over 

the  cnarmel.  Tin  . r.  i jui  ition  L.(>ing  useti  is  illustrated  in 
Fig  10.10. 

10.5.2  Trie  I AXSYS  software 

The  F'aXSYS  softw.ue  can  be  sub-divided  intc5  8 basic  elements. 

These  are: 

1)  The  Real  Tnne  bxocutive 

2)  Fac.simlie  'J'.'nni n.i  1 Drivers 

3)  Console'  Process 

4)  F 10{;py-d  J sk  Handler 

5)  Command  Decoder 

6)  Communications  Controller 

7)  Network  Inter  f.ico 

8}  Compress lon-Decompress ion  process 


During  the  Stage-2  of  the  facsimile  project,  most  of  the  time  was 


Experimental  facsimile  confiqura 


.-T63  - 

spent  in  developing  the  above  coniponents.  Because  of  the  need  I 

to  handle  staging  to  disk,  and  a desire  to  overlap  processes  and  i 

I 

operate  in  a duplex  fashion,  a significant  number  of  tasks  can  i 

i 

be  concurrent.  Thus  there  is  need  for  a small  real-time  executive  (1)  i 

whose  main  functions  arc  to  schedule  the  operation  of  the  software  | 

modules,  act  as  a traffic  controller,  and  maintain  an  efficient 

data  flow  between  different  processes.  The  executive  provides  i 

the  basic  building  blocks  on  which  the  software  can  be  developed.  i 

System  activities  are  reduced  to  a small  number  of  tasks  which  i 

are  activated  on  request  to  the  executive.  Process  scheduling 

is  purely  asynchronous  with  all  processes  being  written  so  that  j 

suspension  can  take  place  at  any  time,  in  favour  of  a higher  i 

priority  process.  ■ 

Modules  2-5  are  standard  ones  which  require  no  comment.  | 

The  Communications  controller  (6)  consists  of  the  modules 
which  pass  data  in  two  streams  via  the  PDP9  to  ARPANET.  This 
is  the  segment  which  had  to  be  changed  for  the  attempt  to  pass 
data  through  the  TIP  character  ports.  I 

The  Network  Interface  (7)  is  a primitive  Network  Access  ' 

• \ 

Machine  (NAM) . Its  main  functions  arc  the  opening  and  closing  i 

of  the  network  connections,  and  interfacing  with  the  remote  j 

subsystems  (e.g.  MSG) . In  the  case  of  the  Datacomouter  access,  , 

it  qenerates  the  necessary  Data-Language  commands  to  perform  a j 

given  function.  This  module  is  complex,  and  is  one  that  needs  i 

modification  as  the  system  functions  are  to  be  expanded.  ^ 

♦ i 

The  Compression-Decompression  process  takes  the  raw  data 
coming  from  the  facsimile  scanner,  and  compresses  it  by  a form 
of  run  length  encoding  (Kirstein,  1976A).  It  also  formats  the 
data  into  a canonical  form,  so  that  a facsimile  device  with 
different  characteristics  could  output  the  data.  In  the  reverse 
direction,  this  module  operates  in  the  reverse  manner. 

10.5.3  The  Present  Status 


Most  of  the  user  functions  of  Section  10.3  were  possible  at 
the  end  of  1976.  The  connection  to  the  network  was  still  in  a 
rather  awkward  form,  as  mentioned  in  Section  10.5.2,  but  this 


I 


will  be  remedied  e..u‘ly  in  l‘)77  - by  pnssiiuj  entirely  via  the 

Mot  all  the  facilities  of  Fip  10. 5 arc  yet  available.  The 
principal  shor tcominqs  are: 

1.  Files  are  restricted  to  1 paqe 

2.  Path  Name  notification  is  in  tlie  Messaqe 
Te.xt  not  the  Subject  Field 

3.  There  is  no  user-suppi i ed  File  Name 

4.  There  is  only  one  common  FACSIMILE  node  used  for  all  files 
on  the  Da tacomputcr , so  that  there  is  no  privacy  from  other 
users 

5.  Messaqe  composition  t'dilim)  commamls  are  somewhat  poorer. 

However,  all  basii-  elements  of  the  system  are  operational,  and 
no  fundamental  reasons  are  known  wh\'  the  whole  system  should  not 
be  implemented  as  planned. 


CHAPTER  1 1 ; 


CONCLUSIONS 


It  would  be  nice  to  be  able  to  present  a nximber  of 
conclusions  and  pinpoint  accurately  whence,  in  this 
report,  the  conclusions  have  been  drawn.  In  most  cases, 
however,  this  is  not  possible.  The  conclusions  follow 
from  the  integration  of  the  different  activities.  We 
indicate  below,  however,  in  which  chapters  research  is 
described  which  leads  to  the  conclusions: 

1.  With  complex  software  for  switching  data,  measurements 
are  essential  to  detect  inefficiencies  in  throughput 
and  operation  in  order  to  indicate  areas  for  improve- 
ment (2,3,8) 

2.  With  complex  protocols  for  data  transmission,  it  is 
essential  to  combine  theoretical  analysis,  simulation 

and  measurement  of  performance.  Unanticipated  interactions 
between  different  levels  of  protocol  can  degrade 
performance.  An  example  is  the  duplication  of  sequence 
control  between  lower  level  ARPANET  protocols  and  the 
TCP  (5,7,8). 

3.  In  order  to  measure  systems  performance  as  above,  a 
wide  variety  of  measurement  tools  are  required.  These 
include  traffic  generators  and  line  level  measurements. 

Once  the  tools  are  developed,  they  can  be  applied  to 
many  different  networks  or  interconnections  of  networks 
with  relatively  little  modification  (2-8) . 

4.  The  connection  of  server  hosts  to  networks  poses  many 
problems.  The  UCL  approach  has  been  to  attach  hosts  by 
a front-end  processor  in  which  virtual  calls  are  matched 
from  a network  to  an  access  scheme  supported  by  the  main- 
frame. Not  only  has  this  technique  been  shown  to  work 
well,  with  many  different  computers,  but  a general  approach 
to  this  technique  (SWITCH)  has  been  developed  during  1976; 
it  has  been  applied  successfully  to  several  host  systems. 
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Our  approach  v/ould  work  well  for  netw’ork  to 
network  connection  and  can  be  extended  to  support 
an  X25  interface  (2,3). 

5.  For  useful  attacliment  < > f ln.ists  to  networks,  r.  t oniV 
must  mappings  be  done  at  call  level,  but  also  at 
higher  levels  such  as  the  interactive  terminal  and 
bulk  transfer  support  levels.  In  tlie  first  there 
are  sometimes  character  set  mapping  difficulties; 

in  the  latter  there  are  sometimes  real  discrepancies 
between  the  underlying  assumjjtions  of  the  networks 
and  the  server  host  systems.  These  mappings  have 
been  done  reasonably  successfully  in  the  UCL  projects, 
but  there  are  sometimes  soiae  awkwardnesses  in  use 
(2,3,9)  . 

6.  Interworking  between  different  networks  poses  many 
problems  and  various  solutions  have  been  proposed. 

UCL  believe  that  mapping  at  the  virtual  call  level 
is  a very  promising  approach  for  interconnection. 

The  SWITCH  system  is  fully  applicable  to  this  problem. 

The  approach  is  fully  compatible  with  using  X25,  with 
some  modifications,  for  ttie  connection  of  networks 
(4,5,7) . 

7.  For  the  effective  use  of  computers  through  more  than 
one  network  there  may  need  to  be  mapping  of  terminal 
and  bulk  transfer  facilities.  SWITCH  provides  the 
mechanism  for  sucli  mapping  and  it  lias  been  uci  i.  mis  t ra  t Cii 
in  certain  environments  (4,6). 

8.  There  is  a strong  interaction  between  the  techniques  used 
for  provision  of  services  through  <-(mk' 1 1 cn  i ttai  networks 
and  tlie  environments  for  which  the  networks  are  designed. 
There  may  well  be  a real  divergence  here  between  the 
requirements  of  PTT  networks  and  those  of  military 

ones  using  techniques  such  as  packet  radio  and  requiring 
numbers  of  gateways  for  high  availability  (4, 5, 6, 7). 
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The  techniques  discussed  in  this  project  may 
encompass  a broader  area  of  communication 
traffic  than  originally  envisaged.  Examples 
are  digitised  speech,  message  traffic  and 
f acs imi le  (4,7,10). 

10.  We  have  been  amongst  the  first  groups  to  have 
used  the  BBN  XNET  debugger  to  do  real-time  program 
monitoring  and  debugging  via  a tenuous  link.  The 
software  in  the  UCL  PSP  Gateways  (Chapter  7)  is 
controlled  on-line  from  US  Tenex  sites  via 
ARPANET  for  debugging  purposes.  This  approach  to 
program  development  has  been  found  to  work  well  (7). 

11.  The  development  of  mappings,  at  call  level  and  higher, 
between  external  and  internal  conventions  as  in 
SWITCH  has  another  corollary.  The  internal 
conventions  need  not  be  restricted  to  one  computer 
but  can  apply  across  several  computers  (some  of 
which  may  even  be  remote) . This  erodes  the  dividing 
line  between  a "single  gateway"  or  a "gateway 
system".  This  "gateway  system"  may  itself  be  a 
computer  network.  The  whole  process  between 
"single  computer"  , "computer  networks"  and 
"distributed  computing"  is  hereby  becoming  blurred 
(2,3,4) . 

12.  In  several  projects  at  UCL,  higli  level  languages  have 
been  used  on  small  computers  via  cross-compilation 
(Babbage  on  the  PDP9/RL  360  and  BCPL  on  the  PDPll). 

There  is  still  no  clear  indication  that  the 

approach  is  really  sufficiently  convenient  in  operation, 
or  efficient  in  code  produced,  to  be  really  viable. 

Even  in  our  own  group  the  opinions  still  differ. 

Some  compl'-'in  that  the  awkwardness  of  having  to  use 
several  systems  together  outweigh  the  advantages  in 
cross-compilation;  there  is  also  clear  evidence  that 
the  code  produced  is  larger  and  slower  by  a sufficient 
factor  that  manual  recotUng  may  be  necessary  and 
too  much  extra  memory  required.  At  the  least  a high- 


availability  lar<jL'  central  host  and  local  access  coir.pater  arc- 
re^:utred.  The  file  -aeripiierals  on  the  latter  nir.at  be  I'-' 
compatible  with  the  machine  for  which  code  is  being 
produced,  or  that  machine  must  also  be  on-line  (2,5,7,8,10). 

13.  The  principle  UCL  activit'es  in  the  Packet  Satellite  Project 
have  been  to  develop  tools  for  traffic  generation  and 

data  acquisition.  Measurement  tools  have  beet  developed, 
but  in  the  absence  of  Gateway  computers  at  other  sites, 
no  real  UCL  measurements  have  been  made  in  1976  (7). 

14.  The  user  level  measurements  are  giving  significant  information 
on  pattern;;  of  network  usage,  on  the  usage  characteristics 

of  different  applications,  and  of  the  performance  of  all 
the  subsystems  available.  The  measurement  tools  should  be 
run  consistently  and  continually,  and  preferably  cover  all 
types  of  access,  for  highest  credibility  (8,9). 

15.  Complex  traffic  generators,  data  acquisition  and  measurement 
data  reduction  all  require  sizeable  amounts  of  computer  soft- 
ware. Careful  attention  to  flexibility  in  the  design  stage 
of  these  tools  pays  off  in  the  ease  with  which  they  can  be 
extended  to  new,  unanticipated  applications  (2, 5, 7, 8). 

16.  For  efficient  network  usage,  facilities  such  as  message 
systems  and  file  transfer  are  essential.  It  is  essential 
also  to  provide  adetjuate  user  information  on  status  of 
connection  and  jobs,  and  on  use  of  facilities  (9) . 

17.  Usage  of  a network  for  collaborative  work  depends  heavily 
on  the  availability  for  each  of  the  collaborating  groups 
involved  of  a local  attached  host  (9). 

18.  The  facsimile  services  envisaged  would  be  of  great 
benefit  to  ARl’ANLT  users-  their  potential  are  far  greater, 
of  course,  in  wider  contexts.  They  could  be  provided  with 
the  facilities  now  available  on  ARPANET.  Initial  economic 
studies  look  promising  for  private  networks  - wider 
development  on  PTT  networks  is  closely  bound  with  PTT 
tariff  and  policy  consideration ( 10) . 
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19.  However  well  information  status  facilities  and 
basic  network  services  are  provided,  it  is  essential 
that  personal  user  support  be  available.  Clearly 

no  new  service  could  be  introduced  without  considerable 
attention  to  documentation  on  user  facilities. 

However,  our  experience  is  that  almost  every  user 
(including  these  inside  our  group! ) comes  to  require 
personal  intervention  of  our  user  liaison  services 
at  some  time.  The  amount  of  effort  required  to  solve 
the  problems  is  variable,  it  may  be  a small  piece  of 
information,  it  may  require  a few  messages  to  other 
sites,  it  may  require  a large  UCL  software  development, 
or  it  may  be  insoluble  and  suggestions  to  circumvent 
the  problem  may  be  needed.  Ho.,ever  we  believe  that 
without  a specialised  liaison  officer  (knowing  something 
about  iUlPANET , UCL. and  RL  etc.)  most  applications  would 
make  significantly  slower  progress;  probably  the  majority 
would  give  up  deeming  their  problems  insoluble  (2, 3, 5, 7, 9). 

20.  Given  the  level  of  technical  and  user  support  provided 
in  the  UCL  ARPANET  project,  very  significant  and  useful 
work  is  now  being  done  collaboratively . Some  of  this 

work  will  be  transferable  to  commercial  services  by  1978,  j 

others  will  not  because  of  the  unavailability  of  the  i 

relevant  US  sites  via  international  commercial  services 
(both  for  economic  factors  caused  by  low  average  usage 
and  by  local  political  constraints)  (9). 
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APPENDIX  A 

Applications  to  Use  ARPANET  approved  for  Use  during  1976 


Name  & Organisation 

Mr.  F.  Grover, 

Blacknest  Research  Est. 
Brimpton,  Reading. 

Dr.  J.  Alcock, 

Dept,  of  Physics, 
BUstol  University 
Tyndall  Avenue, 

Bristol . 


Project  Site  Used 

Seismic  Data  Exchange  ISI 


Collaborative  analysis  LBL 
of  high-energy  scatter- 
ing data 


Dr.  A.J.  Harley, 

British  Library  Lending 
Division, 

Boston  Spa, 

Wetherby,  Yorks. 

Dr.  P.L.  Holmes, 

British  Lib.  Res  & Dev. 
Dept . , 

Sheraton  House, 

Gt . Chapel  St . , 

London , W . 1 . 

Dr.  P.  Humphreys, 
Decision  A.nalysis  Unit, 
Brunei  University, 
Kingston  Lane, 

Uxbridge,  Middx. 

Dr.  J.  Fitch, 

Cambridge  U.  Computer 
Lab.  , 

Corn  Exchange  St. , 
Cambridge . 

Prof.  M.V.  Wilkes, 
Cambridge  U.  Computer 
Lab . 


Dr . M .D  .C  Dyne  , 

Dept,  or  Engineering, 
University  of  Cambridge 

Dr.  G.D.  Cain, 

Dept,  of  Electrical  8 
Electronic  Eng. 
Polytechnic  of  Central 
London , 

115  New  Cavendish  St., 
London , W. 1 


Interlibrary  loan  NLM 

network  development 


CANCERLINE  database  NLM 

evaluation 


Decision  Analysis 

software  development  ISI 


Collaborative  develop-  ISI 
ment  of  LISP  compiler 
for  algebraic  systems 


Design  study  for  a ISI 

data  ring 

Decision  Analysis  ISI 

software  development 


Digital  Filter  Design 
Techniques  ISI 
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Name  & Organisation 


Pro j ect 


Site  Used 


Dr.  R.  Pye, 
Communication  Studies 
Group , 

Dept,  of  Environmental 
Studies , 

UCL. 


Assessment  of  Inter- 
action between 
Travel  s Telecommun- 
icat  ions 


OFFICE- 1 


Dr.  K.V.  Roberts, 

AEA  Culham  Lab., 

Abincjdon,  Oxon. 

Mr.  V.  Pinkerton, 
Technology  Report  Centre, 
St.  Mary  Cray, 

Kent . 


Fusion  research 
col laborat ion 


Database  evaluation 


BBN  at 
present 

NLM 


Dr.  F.D.  Gault, 

Durham  Particle  Data 
Group , 

University  of  Durham. 

Mr.  M.  Gordon, 

Computer  Science  Dept., 
Edinburgh  University. 

Dr.  J.  Darlington, 

Dept . of  A . I . , 

Edinburgh  University 

Prof.  D.  Michie, 

Machine  Intelligence 
Res.  Unit, 

Edinburgh  University. 

Dr.  G.M.  Bull, 

Head  of  Computer  Systems, 
Hatfield  Polytechnic, 
College  Lane, 

Hatfield,  Herts. 

Dr  . J . Bates , 

Inst,  of  Neurology, 
National  Hospital, 

Uueens  Sq. , W.C.l 

Dr.  D.M.  Bowen, 

Dept,  of  Biochemistry, 
Inst,  of  Neurology, 
National  Hospital. 


Collaborative  dev. 
of  high  energy 
database 


Development  of 
proof -generating 
system 

Program  correctness 
proofs,  program 
synthesis 

Machine  Intelligence 
Res . 


Development  of  BASIC 
Standards 


Natural  language 
analysis  software 


Analysis  of  neuro- 
chemical  data 


LBL 


SU-AI 


SRI-AI 


ILL-NTS 


NBS 


SU-AI 


SUMEX 


L 
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Name  & Organisation 

Project 

Site  Used 

Mr.  L.M.  Popovic, 
School  of  Electrical 
& Electronic  Eng., 
Kingston  Polytechnic, 
Kingston-upon-Thames , 
Surrey . 

Program  generation 
by  formal  general 
methods . 

MIT-OMS 

• 

Dr.  T.  Wilkinson, 

Applied  Psychology  Unit, 
Medical  Research  Council, 
5 Shaftesbury  Road, 
Cambridge . 

Neurophysiology 

collaboration 

BBN 

Mr.  D.  Curry, 

MOD , 

Northumberland  House, 

W.C.  1 . 

Collaboration  with 
US  Army  Material 
Command  HQ 

OFFICE-1 

Dr.  W.J.  Raitt, 
Mullard  Space  Science 
Lab.  , 

Dorking,  Surrey. 

Study  of  Ionosphere 

UCSD 

Mr . B . C . Rowe , 

London  Poly.  Computer 
Unit , 

N.  London  Polytechnic, 
Holloway , N . 7 . 

Survey  analysis 
software  evaluation 

ISI 

Dr.  R.P.  Johnson, 
Chemistry  Dept. , 

N.  London  Polytechnic. 
Holloway,  N.7 

Program  development 
of  C.A.  Synthesis 
design  of  organic 
molecules 

HARV-10 

Dr.  T.  Quirk, 

Dept,  of  Nuclear  Physics, 
Oxford  University. 

Exchange  of  software 
of  data  for  high 
energy  physics 

ILL-NTS 

HARV-10 

■ 

Mr.  S.J.  Hague, 

Numerical  Algorithms 
Group , 

Oxford  U.  Computing  Lab. 

Collaboration  in 
Development  of 
numerical  software 
library 

ANL 

- 

Mr.  G.  Coulouris, 

Dept,  of  Computer  Science, 
QMC,  Mile  End  Road,  E. 1 

Investigation  of 
distributed  process- 
ing developments 

RAND-UNIX, 

CMU-A, 

UCB 

Prof.  R.W.  Hockney, 
Dept,  of  C.  Science, 
Reading  University, 
Whiteknights , 

Reading 

Parallel  processor 
evaluation 

Illiac  IV 
ANL 

Dr.  P.  Purcell, 

Dept,  of  Design  Research, 
Royal  College  of  Art, 
Kensington  Gore,  S.W.7 

Program  development 
for  building  design 

HARV-10 

CMU 

MIT-MULTICS 

L 

- 
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Name  & Organisation 


Site  Use 


Mr.  I.R.  Whitworth, 

Royal  Military  College - 
of  Science, 

Shr ivenham, 

Swindon,  Wilts. 

Mr.  N.  Neve, 

Room  L 1 2 1 , 

Royal  Signals  i Radar 
Est . , 

Malvern,  Worcs. 

Dr.  J.M.  Taylor, 

Royal  Signals  & Radar 
Est . , 

Christchurch,  Dorset. 

Dr,  J.  Crennell, 
Rutherford  Lab. 

Prof.  F.  Walkden, 

Dept . of  Maths . , 
University  of  Salford. 

Mr.  T.  Crowe, 

Systems  analysis  Div. , 
Thames  Polytechnic, 
Woolwich,  SE18 

Dr.  L.  Kohout, 

UCH  Medical  School, 

St.  Pancras  Hospital, 

NWl 

Professor  L.M.  Delves 
Dept,  of  Computational 
and  Stat.  Science, 
University  of  Liverpool, 
Brown  low  Hill, 


Digital  signal 
processing 


Support  for  DOD 
evaluation  of  CORAL 


Network  security 


Bubble  chamber  fac- 
ility data  exchange 

Fluid  dynamics 
program  development 


Relational  database 
investigation. 


Neurochemical 
data  analysis 


MIT-AI, 

Utah. 


NELC 

MITRE 

RADC 


ILLIAC-IV 


Datacomputer 
RAND  - UN  I X 


SUMEX-AIM 


Development  of  ALGOL  68  CMU 
Compiler  with  CMU 


Liverpool 


178 


APPENDIX  B 

Non-Active  Users  During  1976 


Name  & Organisation 

Prof.  M.V.  WilXes, 
Cambridge  U. 

Computer  Lab. 

Dr.  M.D.C.  Dyne, 
Cambridge  U.  Dept, 
of  Engineering 

Dr.  G.D.  Cain, 

Central  London  Poly. , 
Engineering  Dept.  , 

Dr.  K.V.  Roberts 
Culham  Laboratory 


Prof.  D.  Michie, 
Edinburgh  U, 

Machine  Intelligence 
Research  Unit. 

Dr.  J.  Bates, 

Inst,  of  Neurology 

Dr.  D.M.  Bowen, 

Inst,  of  Neurology 


Project 

Design  study  for  a 
Data  Ring 


Decision  analysis 
software  development 


Digital  Signal 
Processing 


Plasma  Physics 
Computation 


Machine  Intelligence 


Automated  Analysis  of 
Natural  Medical  Text 

Analysis  of  Neuro- 
chemical Data  at 
Stanford . 


Reason  for  Inactivity 
Lack  of  time 


Cost  of  telephone  calls 
& poor  quality 
telephone  lines. 

Unable  to  make  US 
contacts  for 
collaboration 

Lack  of  time  and  of  the 
availability  at  Culham 
of  ARPANET  host. 

Work  carried  out 
during  visit  to  US  but 
will  resume  shortly 


Illness 


Lack  of  time 


Mrs  L.  Popovic, 
Kingston  Poly., 
School  of  Electrical 
& Electronic  Eng. 


Dr.  W.J.  Raitt, 

Mullard  Space  Science 
Lab. 

Mr.  I.R.  Whitworth, 
Royal  Military  College, 
of  Science 


Formal  and  general 
methods  for  formul- 
ating technological 
problems  for 
computerisation . 

Study  of  Ionosphere 
during  visit  to  US. 


Digital  Signal 
Processing 


Illness 


Work  carried  out 


Unable  to  make  US 
contacts  for 
collaboration 
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KIRSTEIN  PT: 


KIRSTI-JIN  PT: 


KIRS'FFIN  PT: 


KIRSTCIN  PI’: 


HIGGINSON  PL: 


STOKES  AV: 


STOKES  AV, 
KIRS'lEIN  PT 
& BATES  DL: 


PUBLICATIONS  AND  PAPERS  PRESENTED  DURING  HE  REPORTING  PERIOD 


Development  in  EXiropean  Public  Data  Networks, 

Reicluiemetze  und  Datenfernverabeitung,  Informtik- 
Fachberichte  No.  3,  ed.  D.  Flaupt  and  H.  Petersen, 

Berling  and  Heidelberg:  Springer-Verlag,  1976,  39-58 

Data  Connunication  General  Principles.  The  Enc^'clopaedia 
of  Comf^uter  Science,  ed.  C.L.  Meek,  New  York:  Mason/Charter 

1976,  5-6. 

Developments  in  European  Public  Data  Networks.  Proc. 

Conf . on  Conp^uter  Networks  ano  Teleprocessing,  Aachen  (1976) 
38-60. 

Planned  New  Public  Data  Networks,  Ccrputer  Networks,  Vol.l 
No. 2,  Sept.  1976. 

Software  Recpuirements  of  Miniccmpiuter  System  for  Use  as  a 

Gateway  between  Networks.  Minicemp^uter  Software, 

ed.  T.R.  Beil  .ind  C.G.  Dell,  Amsterdam:  North-Holland, 

1976,  257-67. 

Software  Development  in  a Network  Environment  usina  a 
Hiqh-Ijevel  Liinguage.  Minicomi-'uter  Softw.are,  ed.  J.R. 

Bell  .'.md  D.J.  Dell.  Amsterdam:  Nortli-Holland,  1976,  241-55. 

Monitoring  and  Acess  Control  of  the  London  Node  of 
ARPANET'.  Proc.  Nat.  Corputer  Conf.  45(1976)597-603 


